Nimbalyst : piloter Codex et Claude Code depuis un atelier visuel
Ce projet transforme « Nimbalyst - The open-source visual workspace for Claude Code, Codex, and OpenCode. Run multiple coding agents in parallel, edit their work visually in markdown, mockups, and diagrams, and track tasks. Free, MIT-licensed desktop app for macOS, Windows, Linux, with mobile companion for iOS and Android. » en une solution open source exploitable, avec une chaîne d’outils réutilisable et des moyens d’intégration pour des cas d’usage concrets.
En bref
- De quoi s’agit-il ?
- Ce que couvre Nimbalyst : éditeurs WYSIWYG, relecture en diff, sessions parallèles sous git worktree, et les limites que le README admet lui-même.
- À qui s’adresse-t-il ?
- Nimbalyst s'adresse à celles et ceux qui font déjà tourner Codex ou Claude Code et qui perdent du temps à relire des diffs dans un terminal ; il présuppose Git, un poste macOS, Windows ou Linux, et l'acceptation d'une télémétrie PostHog (désactivable). Si votre flux reste en ligne de commande pure, le kanban et l'application iOS n'ajoutent rien.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un atelier visuel branché sur Codex et Claude Code
Nimbalyst se présente comme un espace de travail visuel pour agents de codage, sous licence MIT, distribué en application Electron pour macOS, Windows et Linux. Le README le décrit comme un éditeur visuel local et un gestionnaire de sessions et de tâches destiné aux développeurs, chefs de produit et designers travaillant avec Codex, Claude Code, OpenCode (alpha), Copilot (alpha) et un fournisseur Gemini. L'idée directrice tient en une phrase : l'agent produit, l'humain relit et édite dans le même document, sous forme de fichiers réels. Le projet bouge vite, avec la v0.75.5 publiée le 28 août 2026, une journée après la v0.75.4. Cette cadence plaide pour lire les notes de version avant chaque mise à jour, car l'application reste jeune.
Relire l'agent en diff rouge et vert
La relecture est le cœur du produit. Les modifications proposées apparaissent en diff rouge et vert dans le document rendu, et chaque bloc se refuse ou se valide individuellement. Le README énumère les éditeurs intégrés : markdown, maquettes annotées, Mermaid, Excalidraw, CSV, modèles de données et code sous Monaco. Concrètement, une spécification et un composant se relisent dans le même outillage. Ce parti pris déplace la validation vers l'amont : corriger un nœud d'un diagramme Mermaid à la main coûte moins que relancer l'agent. La contrepartie, non documentée, concerne les fichiers que ces éditeurs couvrent mal ; rien n'indique leur comportement sur des formats exotiques, et il faudra le constater sur vos propres dépôts.
Sessions parallèles cloisonnées par git worktree
Chaque session d'agent s'exécute dans son propre git worktree, l'extrait de travail indépendant que Git sait créer depuis un même dépôt. Deux agents peuvent donc retoucher le projet en parallèle sans s'écraser, et chaque résultat reste fusionnable séparément. Nimbalyst embarque la gestion des branches, le staging, des commits rédigés par IA et un terminal ghostty intégré. Le tableau kanban joue le rôle de poste de pilotage : recherche d'une session, reprise, lien entre une session et les fichiers touchés. C'est ce qui rend les agents simultanés praticables, parce que l'état de chacun reste visible et reprenable au lieu de dormir dans un onglet de terminal.
Tâches partagées et fichiers plats plutôt que base propriétaire
Le suivi de tâches suit le même principe : plans, bugs et fonctionnalités vivent dans des listes que l'agent lit et met à jour pendant que l'humain y écrit aussi. Le mécanisme de synchronisation entre sessions n'est pas décrit dans la documentation fournie ; c'est un point à examiner sur place. Les contenus restent des fichiers ordinaires : markdown pour le contenu et le statut, commandes slash pour les workflows, le tout versionné dans votre dépôt. Le README affirme qu'il n'existe « no proprietary store to migrate out of ». Pour une équipe, cette phrase a une portée pratique : les livrables restent lisibles sans l'application, ce qui limite la dépendance en cas de changement d'outil.
Télémétrie PostHog documentée, canal stable par défaut
L'application envoie des statistiques d'usage anonymes à PostHog ; le désabonnement se fait dans les réglages avancés, rubrique Analytics. Le README promet l'absence de données personnelles : ni noms, ni adresses IP, ni contenus de fichiers, ni clés d'API, avec un identifiant aléatoire par installation. Surtout, la liste complète des événements est publiée dans docs/POSTHOG_EVENTS.md et les règles de confidentialité dans docs/ANALYTICS_GUIDE.md, un niveau de détail peu fréquent pour ce type d'application. Côté versions, une installation neuve suit le canal stable et ne reçoit que les releases promues ; le canal alpha s'active dans Settings, rubrique Advanced, option Release Channel. La documentation prévient que ces builds peuvent casser, et le retour au stable reste possible à tout moment.
Application iOS, client MCP et contrat EditorHost
Une application compagne iOS, écrite en SwiftUI dans packages/ios, montre les agents qui attendent une réponse, permet de répondre par texte ou par voix, de parcourir des diffs au balayage et de mettre en file la tâche suivante. Le client MCP intégré connecte n'importe quel serveur MCP et affiche les résultats d'outils sous forme de widgets plutôt qu'en JSON brut. L'Extension SDK repose sur un contrat unique nommé EditorHost, que suivent aussi les éditeurs intégrés : un éditeur développé en interne a donc le même rang qu'un éditeur livré avec l'application. Les extensions existantes vont de l'éditeur Astro au journal git visuel, en passant par une carte mentale, des diapositives et un éditeur d'objets 3D. Le serveur de synchronisation, joignable à l'adresse wss://sync.nimbalyst.com, reste un projet séparé du dépôt principal.
Installer un binaire ou compiler le monorepo npm
Des binaires sont servis depuis la page des releases : dmg pour macOS 12 et suivants (arm64 et x64), exe pour Windows 10 et suivants, AppImage pour Linux. Pour compiler, le dépôt est un monorepo TypeScript et Electron organisé en npm workspaces : npm install (npm 7 ou plus), puis cd packages/electron && npm run dev pour lancer l'application en mode développement, ou npm run build:mac:local pour un binaire Mac local. Les espaces de travail principaux sont packages/electron, packages/runtime pour les services transverses (IA, synchronisation, éditeur Lexical), packages/collab-protocol pour le format d'échange, packages/extension-sdk et packages/extensions. Le premier pas documenté reste modeste : créer un document avec Cmd ou Ctrl+N et demander à l'agent de le retravailler.
Conclusion éditoriale
Nimbalyst s'adresse à celles et ceux qui font déjà tourner Codex ou Claude Code et qui perdent du temps à relire des diffs dans un terminal ; il présuppose Git, un poste macOS, Windows ou Linux, et l'acceptation d'une télémétrie PostHog (désactivable). Si votre flux reste en ligne de commande pure, le kanban et l'application iOS n'ajoutent rien. Deux vérifications propres au projet s'imposent avant d'adopter : la stabilité réelle du canal stable au regard de la cadence v0.75.3 à v0.75.5 d'août 2026, et l'inventaire exact des événements télémétrés dans docs/POSTHOG_EVENTS.md. Lancez ensuite npm run dev depuis packages/electron sur un dépôt jetable pour juger la relecture en diff sur vos propres fichiers.
Notes de la communauté