Un seul backbone d'événements. Zéro fournisseur préprogrammé.
Toute source d'événement. Tout résultat commercial. Une seule plateforme. Voici la pile multi-tenant complète, native de Kubernetes, sous chaque automatisation prête à l'emploi.
Connecteurs
- Appels HTTP sans état
- Légers, sans démarrage à froid
- REST / GraphQL / Webhooks
Agents
- Pods K8s isolés
- À longue exécution, avec état
- IA / LLM / Messagerie
La pile complète de la plateforme
Huit couches, un seul contrat. Chaque couche est déployable et observable de manière indépendante — et chaque requête est finalement acheminée via le backbone de CloudEvents.
Visuel pour les opérateurs, code pour les développeurs.
Authentification, scope organisationnel et l'API avec laquelle chaque interface communique.
Fait correspondre les événements par modèle, cron ou webhook et exécute le graphe.
Le seul contrat parlé par chaque intégration. Fortement mis en avant car tout transite par lui.
Les connecteurs appellent les APIs ; les agents raisonnent dans des pods isolés. Les mêmes packages alimentent les deux.
Conteneurise et déploie les agents dans des namespaces de locataires isolés.
État relationnel, historique des événements sous forme de séries temporelles, cache et mémoire d'agent.
Cluster multi-tenant avec chiffrement, politiques de réseau et observabilité complète.
Ce que la pile vous apporte
Portail CloudEvents
Toutes les sources d'événements (webhooks, planifications, bases de données, messagerie, APIs) sont normalisées sous le contrat CloudEvents 1.0 sur un backbone Kafka, permettant aux modèles d'orchestrer sans code de liaison personnalisé.
SDK & CLI d'Agents en TypeScript
Concevez et déployez des agents en TypeScript. Initialisez avec init, testez en local et déployez avec push (HTTP pur, sans Docker local requis).
Concepteur visuel de workflow
Un concepteur visuel en glisser-déposer basé sur le moteur Prefect — 42 types de nœuds (condition, filtre, boucle, transformation, HTTP, exécution d'agent, action de connecteur, tâche humaine) et historique d'exécution en direct.
Connecteurs basés sur Schéma comme Contrat
Les intégrations sont des données, pas du code. Chaque connecteur est un package versionné validé par rapport à un schéma canonique servi par l'API avant de pouvoir être publié — le catalogue évolue sans toucher au noyau.
En Temps Réel & Observable
Mises à jour WebSocket en direct avec reconnexion automatique, ainsi qu'OpenTelemetry, des métriques Prometheus, des tableaux de bord Grafana et une page d'état publique sans token.
Sécurité Multi-Tenant
Authentification JWT, RBAC avec 4 rôles, namespaces Kubernetes par tenant, requêtes limitées par organisation, TLS 1.3 et masquage des données personnelles (PII) — validé par 47/47 contrôles de sécurité.
Bâti sur une pile moderne et ouverte
Pourquoi cette architecture s'impose
Indépendant des fournisseurs par nature
Il n'y a aucune logique de fournisseur figée dans le noyau. Le même moteur exécute WhatsApp, Stripe et Salesforce — et les cent suivants — via le contrat commun. Un connecteur n'est considéré comme « terminé » que lorsqu'il comprend son package de fournisseur, son package de connecteur, sa documentation de 7 fichiers et ses tests unitaires fonctionnels : pas de travail incomplet.
Exécution guidée par les événements
Contrairement aux plateformes basées sur l'interrogation (polling), Zervanor est entièrement piloté par les événements. Les workflows et les agents ne s'activent que lorsqu'un événement auquel ils sont abonnés (comme stripe.payment.succeeded ou github.issue.opened) transite par le Routeur d'Événements.
Runtime natif de Kubernetes
Zervanor ne se contente pas d'appeler vos APIs, il héberge vos agents. Chaque agent est conteneurisé et déployé au sein d'un cluster multi-tenant sur GKE, avec une isolation au niveau des pods et des namespaces par organisation. L'historique des événements réside sur TimescaleDB et l'observabilité fonctionne sur OpenTelemetry et Prometheus.