Kun : un runtime local partagé entre GUI et TUI, sous licence non commerciale

Le problème visé : un agent qui travaille dans un projet réel, pas dans une fenêtre de chat

La plupart des assistants de code s'arrêtent à la réponse. Kun se présente comme un poste de travail où l'agent lit le contexte du workspace, forme un plan, appelle des outils, modifie des fichiers, lance des vérifications et laisse les preuves à côté de la tâche. Le README décrit une boucle en cinq temps : clarifier l'objectif, former un plan, exécuter et collaborer, inspecter les preuves, livrer ou continuer. Le public visé est double. D'un côté un développeur qui construit, débogue et publie du logiciel, avec un mode Code qui regroupe contexte projet, édition de fichiers, terminal, Git et Worktree, Diff, tests et revue. De l'autre un profil plus rédactionnel, avec un mode Work qui édite du Markdown, prévisualise et cite des PDF ou des fichiers Office, analyse des tableurs et génère des présentations à partir d'un plan. Les fichiers Office restent en lecture seule, ce qui borne d'emblée ce qu'on peut attendre du mode Work. Le README précise aussi que les besoins et les plans peuvent être conservés dans le projet par défaut, donc versionnables, relus en revue de code et restaurés plus tard. C'est cette conservation dans le dépôt qui distingue Kun d'un client de chat dont l'historique vit dans une base opaque.

Un seul kun serve derrière deux interfaces

Le point d'architecture central est énoncé sans détour dans le README : la GUI de bureau et la TUI partagent le même runtime local, et non deux sessions séparées. Threads, objectifs, plans, approbations et tâches d'arrière-plan sont donc communs aux deux. On peut décrire la topologie ainsi : un processus kun serve détient l'état, la GUI Electron sert à observer, relire et contrôler le déroulement, la TUI sert au travail au clavier. Le README indique que les deux peuvent se connecter simultanément au même runtime. La commande à lancer depuis un répertoire de projet est simplement kun. Cette architecture a une conséquence pratique souvent négligée : ce qui est approuvé dans une interface est visible dans l'autre, ce qui évite la divergence classique entre un agent lancé dans un terminal et un agent lancé dans une fenêtre. Elle a aussi une conséquence de disponibilité. Depuis la version 0.3.8, l'archive TUI n'est plus distribuée séparément : il faut passer par la commande terminal intégrée à l'application de bureau, comme le note le README, qui renvoie à docs/kun-tui.md pour la configuration. Autrement dit, la TUI n'est plus un point d'entrée autonome pour qui ne veut pas installer Electron.

Modes Code et Work, et le passage Design vers Code

Kun organise le travail en deux modes principaux. Code cible la livraison logicielle et embarque un canevas Design dans la même tâche, ce qui permet de déposer prototypes, design system et contexte Design vers Code sans quitter la tâche en cours. Work cible l'écriture, la mise en forme de documents et l'analyse de pièces jointes. Le README mentionne aussi des tâches planifiées, des Loops, des Hooks, le support MCP, des Skills et des extensions installables pour l'automatisation de processus répétitifs. Ces briques sont documentées dans des fichiers distincts : docs/workflow-loop.md, docs/project-mcp-skills.md et docs/extensions/README.md. Le choix de faire cohabiter Design et Code dans un même mode est un parti pris. Il évite de perdre le contexte de conception au moment de coder, au prix d'une interface plus chargée et d'un modèle mental à acquérir. Le README ne détaille pas comment le canevas Design est stocké ni comment il se synchronise avec les fichiers du projet, et cette zone reste floue à la lecture du matériel fourni.

Local-first ne veut pas dire hors ligne

Le README consacre un passage explicite à cette nuance : sessions, préférences, journaux et données de runtime restent sur la machine par défaut, mais dès qu'un modèle cloud est choisi, les prompts, les pièces jointes et le contexte de tâche partent vers le Provider sélectionné. L'utilisateur est renvoyé à la politique de données de ce service. C'est une honnêteté appréciable, parce que le terme local-first est souvent employé pour suggérer une confidentialité totale qui n'existe pas dès qu'un modèle distant est branché. Kun ne s'enferme pas dans un fournisseur unique : le README cite des presets couvrant ChatGPT / Codex, Claude, Gemini, Cursor, Ollama, DeepSeek, Kimi, GLM, Qwen, MiniMax et Xiaomi MiMo, avec des connexions par abonnement, plan, API, services compatibles OpenAI ou Anthropic, et modèles auto-hébergés. Il précise toutefois que les modes de connexion, les modèles, les régions et les quotas dépendent de la version courante et des règles du Provider, et renvoie à docs/model-provider-presets.md. Les permissions d'outils, les opérations sensibles et les droits des extensions sont présentés dans l'interface, et l'autorisation reste à la charge de l'utilisateur. Rien dans le matériel fourni ne permet de dire comment ces approbations sont stockées ni si elles sont journalisées.

Installation et commandes de développement

Pour un utilisateur, le README renvoie aux GitHub Releases : .dmg ou .zip pour macOS en Apple Silicon et Intel, .exe pour Windows en x64, .AppImage ou .deb pour Linux en x64. Au premier lancement, trois étapes sont décrites : choisir la langue et configurer un abonnement, un plan, une API ou un Provider personnalisé ; ouvrir un projet local ou créer un workspace ; envoyer une tâche à objectif clair, à périmètre limité et vérifiable. Pour partir des sources, les prérequis annoncés sont Node.js 22.19 ou plus récent, npm, et au moins une connexion à un modèle. La séquence est classique : git clone https://github.com/KunAgent/Kun.git, puis cd Kun, npm ci, npm run dev. Le tableau des scripts distingue npm run dev (construit le runtime et lance l'environnement Electron de développement), npm run dev:tui (construit le runtime et lance la TUI terminal), npm run typecheck, npm run lint (ESLint plus un contrôle de taille de fichiers), npm run test, npm run build, et les cibles de packaging dist:mac, dist:win, dist:linux. En cas de réseau lent depuis la Chine continentale, le README propose npm ci --registry=https://registry.npmmirror.com. Le contrôle de taille de fichiers dans npm run lint est un détail parlant : il indique que le projet cherche à contenir la dérive des gros modules, contrainte fréquente sur une base TypeScript de cette ampleur.

Licence et coût de maintenance

La licence est le point à examiner avant toute autre considération technique. Le README et le badge annoncent PolyForm Noncommercial 1.0.0, réservée à l'étude, la recherche et un usage non commercial. Le texte précise que l'usage commercial, la distribution commerciale, les services SaaS ou hébergés, la revente et l'intégration dans un produit commercial exigent une autorisation écrite séparée de l'auteur. À noter une incohérence à vérifier : l'API du dépôt renvoie NOASSERTION comme identifiant de licence, ce qui signifie que l'outillage n'a pas reconnu le fichier LICENSE. Cela ne change pas le contenu du fichier, mais cela complique l'analyse automatique de conformité dans une chaîne d'intégration. Sur la maintenance, les éléments disponibles sont factuels : trois versions publiées en peu de temps, v0.3.7 le 28 août 2026, v0.3.8 et v0.3.9 le 6 septembre 2026, et un dernier push sur master daté du 9 septembre 2026. Le README indique que la branche d'intégration quotidienne est develop et que les pull requests doivent la cibler, avec une contribution externe soumise à un CLA. Un rythme de publication aussi resserré implique de relire les notes de version avant de mettre à jour, en particulier parce que la distribution de la TUI a changé en 0.3.8. Rien dans le matériel fourni ne permet d'évaluer la stabilité de l'API d'extension ni la politique de dépréciation.

Quand Kun n'est pas le bon outil, et ce qui existe à côté

Kun suppose une machine de bureau et une interface graphique installée. Si votre besoin est un agent qui tourne dans un conteneur sans affichage, ou une bibliothèque appelée depuis votre propre code, ce n'est pas la bonne cible : la TUI elle-même n'est plus distribuée seule depuis 0.3.8. La licence ferme par ailleurs la porte à toute intégration dans un produit vendu, à un service hébergé ou à une revente sans accord écrit. Sur ce terrain, un outil comme Aider adopte une approche différente : c'est un outil en ligne de commande centré sur l'édition de code dans un dépôt Git, sans runtime de bureau persistant ni état partagé entre plusieurs interfaces, et il est distribué sous licence Apache 2.0, donc utilisable dans un contexte commercial. La différence n'est pas cosmétique : Kun maintient un processus serveur local qui détient threads, plans et approbations, avec une GUI et une TUI branchées dessus, alors qu'Aider s'exécute dans le terminal et s'arrête avec lui. Si votre contrainte principale est l'intégration dans une chaîne commerciale, la licence de Kun est éliminatoire avant même de comparer les fonctionnalités. Si votre contrainte est de garder un état de tâche consultable et approuvable depuis deux interfaces, l'architecture de Kun répond à un problème qu'Aider ne cherche pas à résoudre.

Conclusion éditoriale

Kun convient à un développeur ou un rédacteur seul, sur macOS, Windows ou Linux, qui veut garder ses sessions, préférences et journaux sur sa machine et accepter une licence PolyForm Noncommercial 1.0.0, donc sans usage commercial, SaaS ni revente sans autorisation écrite. Il ne convient pas à une équipe qui doit intégrer un agent dans un produit vendu, ni à un utilisateur qui refuse d'envoyer ses prompts à un Provider cloud. Avant d'adopter, vérifiez deux points dans le dépôt : le fichier LICENSE, puisque l'API GitHub renvoie NOASSERTION alors que le README annonce PolyForm Noncommercial 1.0.0, et le contenu de docs/model-provider-presets.md pour confirmer qu'un Provider compatible OpenAI ou Anthropic est bien pris en charge par la version que vous installez.

Sources officielles

1. Issues
2. KunAgent/Kun on GitHub
3. Project website
4. README
5. Releases