Qu’est-ce que Evenfire ?
Evenfire est une plateforme open source pour faire tourner des agents LLM dans votre propre cluster Kubernetes. Les agents échangent avec les gens via une application de bureau, Telegram, Microsoft Teams, Slack et l'e-mail, appellent des outils via MCP, exécutent des commandes shell, font des requêtes HTTP et pilotent un navigateur. Les commandes, le HTTP sortant et le contrôle du navigateur attendent qu'une personne les approuve depuis le canal avant de s'exécuter.
Agents, connecteurs, canaux, workflows, politiques et plugins sont des ressources personnalisées Kubernetes, neuf en tout, donc la flotte vit dans le contrôle de version. Chaque agent tourne dans son propre pod, dans un namespace qui démarre sans aucun accès réseau ; les connecteurs sont ouverts agent par agent, et des budgets de tokens peuvent bloquer ou avertir par périmètre. Il est livré avec une Control UI pour les administrateurs, une application de bureau Electron et une page de profil pour les invitations, et fonctionne avec 24 fournisseurs de modèles sur vos propres clés.
Le code est en TypeScript sous MPL-2.0 et en bêta, en v0.12.0. La plateforme mono-tenant est complète dans le dépôt ; Evenfire, l'entreprise, vend un service hébergé multi-tenant avec support et SLA, à des prix qu'elle ne publie pas. Le code utilise le nom interne clerum.
Evenfire vaut-il le coup ?
Evenfire traite la sécurité des agents comme un problème d'infrastructure plutôt que de prompt, et c'est son meilleur argument. Chaque agent a son propre pod, les namespaces d'exécution démarrent sans connectivité, les connecteurs sont ouverts agent par agent avec des jetons à courte durée et à périmètre limité, et les appels d'outils risqués sont suspendus jusqu'à ce que quelqu'un les approuve dans Slack, Teams ou Telegram. Des frameworks comme LangGraph laissent ces contrôles à l'application ; ici, c'est la plateforme qui les impose.
Les réglages par défaut méritent une lecture attentive. Les pods d'agents peuvent atteindre l'internet public sur les ports 80 et 443 pour appeler les API de modèles et l'outil HTTP soumis à validation, tandis que les plages privées et de métadonnées restent bloquées. La liste d'images autorisées pour les connecteurs est désactivée tant que vous ne définissez pas CONTROL_API_ENFORCE_IMAGE_ALLOWLIST=true, et l'overlay minikube active les connexions par abonnement ChatGPT et Grok que le déploiement de base laisse désactivées. Les clusters de production ont besoin d'un plugin réseau compatible NetworkPolicy comme Calico, faute de quoi l'isolation n'existe pas.
Le coût d'exploitation est réel. L'essai local exige Docker avec au moins 10 Go de mémoire et six CPU, minikube, kubectl, Node.js 24, Python et Ruby, et prend environ 15 minutes avec un cache vide. La production implique d'adapter les overlays kustomize à votre propre cluster, de gérer les clés de signature et les secrets, et de faire tourner plus de vingt services. Une équipe sans compétences Kubernetes passera ses premières semaines sur la plateforme, pas sur les agents.
La maturité reste la question ouverte. Le projet a quatre mois, avec 575 étoiles, des versions jusqu'à la v0.12.0 le 28 octobre et des commits aussi récents que le 5 novembre, mais aussi 793 issues et pull requests ouvertes. Les plus récentes sont précises et parfois sérieuses : des jetons de fichiers GFS qui survivent à une déconnexion, un compte recréé en rejouant une ancienne invitation, une compaction de contexte qui échoue sur les modèles de raisonnement d'OpenAI. Les déclarer en public est bon signe ; les mainteneurs préviennent que les API et les CRD peuvent changer avant la 1.0.
Par rapport à OpenClaw, qui installe un assistant personnel sur votre téléphone en un après-midi, Evenfire vise les équipes plateforme qui ont besoin de nombreux agents, de nombreux utilisateurs et d'une piste d'audit. Dify mène une équipe plus vite à un agent fonctionnel mais encadre bien moins ce que cet agent peut toucher.
Là où il fait la différence
Une équipe plateforme dans une entreprise SaaS de 300 personnes avec un cluster EKS existant
Laisser un agent d'exploitation lancer des commandes de diagnostic sans lui laisser le champ libre
Déclarez l'agent et ses connecteurs en CRD, gardez shell_exec derrière la validation pour que chaque commande attende un ingénieur d'astreinte dans Slack, et fixez un budget de tokens pour l'équipe. Le coût est la capacité du cluster plus les dépenses de modèles sur vos propres clés.
Un responsable informatique dans une entreprise réglementée qui ne peut pas envoyer de données à un fournisseur d'assistant hébergé
Donner au personnel un assistant partagé dans Teams qui reste sur notre infrastructure
Auto-hébergez sur un cluster interne avec une clé pour Bedrock ou Vertex AI ; les prompts ne vont qu'à ce fournisseur, les lectures et écritures sur le disque partagé sont journalisées, et les invitations passent par la Profile UI. Le support est uniquement communautaire sans l'offre hébergée.
Un développeur qui évalue des plateformes d'agents sur un portable
Voir si le modèle de validation et d'isolation convient avant de le proposer
Lancez make minikube-setup avec une clé de modèle ; un agent chatllm préconfiguré répond dans l'application de bureau après environ 15 minutes de téléchargement d'images. Il faut 10 Go de mémoire libre pour Docker.
Avant de vous engager
- Mise en route
- Essai local : clonez, définissez ADMIN_PASSWORD et une clé de modèle dans .env, lancez make minikube-setup (environ 15 minutes à froid) avec Docker à 10 Go de mémoire et six CPU, minikube 1.30+, kubectl, Node 24, Python et Ruby. Production : adaptez deploy/overlays à un cluster avec Calico ou équivalent.
- Intégrations
- Telegram, Slack, Microsoft Teams, l'e-mail et une application de bureau comme canaux ; connecteurs MCP dont MongoDB et Airtable ; 24 fournisseurs dont OpenAI, Anthropic, Bedrock, Vertex AI, Azure OpenAI et OpenRouter ; registre de plugins ; GitOps via les CRD.
- Données et confidentialité
- Auto-hébergé ; prompts et fichiers ne vont qu'au fournisseur de modèles que vous configurez. L'accès aux fichiers partagés est vérifié et audité à chaque requête. Le hub d'inscription partagé optionnel envoie les e-mails d'invitation en votre nom. MPL-2.0.
- Coût à grande échelle
- L'auto-hébergement coûte la capacité de cluster pour plus de 20 services et un pod par agent, plus les dépenses de modèles sur vos clés ; les budgets de tokens les plafonnent par périmètre. Le prix du service hébergé n'est pas publié.
- Limites
- Une organisation par déploiement auto-hébergé ; support communautaire sans SLA ; API en bêta ; 793 issues et pull requests ouvertes, dont des bugs de déconnexion et de rejeu d'invitation.
Les points forts
- Validation humaine sur le shell, le HTTP sortant et les actions de navigateur
- Un pod par agent avec réseau fermé par défaut
- Toute la flotte déclarée en neuf CRD Kubernetes
- 24 fournisseurs de modèles sur vos propres clés
- Plateforme mono-tenant complète sous MPL-2.0, sans fonctions bridées
Les points faibles
- Exige des compétences Kubernetes et un cluster compatible NetworkPolicy
- Bêta : les API et les CRD peuvent changer avant la 1.0
- 793 issues et pull requests ouvertes, certaines liées à la sécurité
- Liste d'images autorisées désactivée par défaut ; prix de l'offre hébergée non publié
Idéal pour
Équipes plateforme qui font déjà tourner Kubernetes et ont besoin de plusieurs agents avec un vrai accès aux systèmes, partagés entre utilisateurs, sous validations, budgets et journaux d'audit.
Alternatives à Evenfire
Evenfire : questions fréquentes
- Evenfire vaut-il le coup ?
- Evenfire entoure de garde-fous sérieux les agents qui touchent des systèmes de production, au prix de l'exploitation d'une plateforme Kubernetes encore en bêta. Nous lui donnons 3.6 sur 5.
- Combien coûte Evenfire ?
- Gratuit sous MPL-2.0 en auto-hébergement, une organisation par déploiement. Service hébergé multi-tenant avec support et SLA ; prix non publié.
- Quels sont les inconvénients de Evenfire ?
- Exige des compétences Kubernetes et un cluster compatible NetworkPolicy; bêta : les API et les CRD peuvent changer avant la 1.0; 793 issues et pull requests ouvertes, certaines liées à la sécurité; liste d'images autorisées désactivée par défaut ; prix de l'offre hébergée non publié.
- À qui s’adresse Evenfire ?
- Équipes plateforme qui font déjà tourner Kubernetes et ont besoin de plusieurs agents avec un vrai accès aux systèmes, partagés entre utilisateurs, sous validations, budgets et journaux d'audit.
- Combien coûte Evenfire pour une équipe ou en production ?
- L'auto-hébergement coûte la capacité de cluster pour plus de 20 services et un pod par agent, plus les dépenses de modèles sur vos clés ; les budgets de tokens les plafonnent par périmètre. Le prix du service hébergé n'est pas publié.
- Evenfire est-il sûr pour les données de l’entreprise ?
- Auto-hébergé ; prompts et fichiers ne vont qu'au fournisseur de modèles que vous configurez. L'accès aux fichiers partagés est vérifié et audité à chaque requête. Le hub d'inscription partagé optionnel envoie les e-mails d'invitation en votre nom. MPL-2.0.
- Quelles sont les meilleures alternatives à Evenfire ?
- Les alternatives les plus proches que nous avons testées sont OpenClaw, Dify et n8n.
Réponses vérifiées le 5 nov. 2026.