- ▸ Prise en main : 47 minutes du téléchargement au premier dispatch
- ▸ Test en conditions réelles : 30 tickets dispatchés sur trois dépôts
- ▸ Cas 1 — Audit de sécurité parallèle sur le backend Python
- ▸ Cas 2 — Refactor Next.js avec dépendances entre cartes
72 heures, une trentaine de tickets dispatchés, trois dépôts Git distincts. Verdict : Kanbots tient sa promesse d’orchestration parallèle, mais demande de la rigueur côté repo.
| Critère | Score |
|---|---|
| Prix | Gratuit à vie · dons « Pay-what-you-can » |
| Licence | MIT (open source) |
| Disponibilité | Application desktop · macOS, Linux, Windows |
| Catégorie | Outil de gestion d’agents IA sur Kanban |
| Note Léo | 7,8 / 10 |
Points clés – Dispatch parallèle : chaque carte Kanban devient un agent IA autonome, isolé dans son propre
git worktree. – Architecture branche-par-ticket : Kanbots crée une branchekanbots/issue-Npour chaque agent, ce qui élimine les conflits de merge en cours d’exécution. – Board live : décisions, coûts cumulés et statut des runs remontent en temps réel, sans rafraîchissement manuel. – Modèle économique : MIT licensed, gratuit pour toujours, dons libres selon le site officiel publié le 1er janvier 2026. – Pour qui : développeurs solo, tech leads qui pilotent plusieurs chantiers en parallèle, équipes qui veulent industrialiser leurs agents sans payer une plateforme SaaS.
J’ai installé Kanbots le mardi soir, lancé mon premier ticket le mercredi matin, et bouclé une trentaine de runs en trois jours. L’outil, distribué sur kanbots.dev, vise un créneau précis : permettre à un développeur de transformer sa colonne « À faire » en parc d’agents IA qui bossent en même temps, chacun sur sa propre branche Git. Ce n’est ni Linear, ni Jira, ni un wrapper autour de Claude Code. C’est une application desktop qui orchestre des runs d’agents et expose leurs décisions dans une interface Kanban classique.
Je détaille ci-dessous mon protocole de test, les forces et les limites observées, et un comparatif avec deux alternatives directes que j’utilise au quotidien.
Prise en main : 47 minutes du téléchargement au premier dispatch
J’ai téléchargé le binaire macOS depuis le site officiel un mardi soir à 21 h 14. Installation classique en .dmg, glisser-déposer dans /Applications, premier lancement à 21 h 19. L’onboarding ne demande pas de compte cloud : Kanbots tourne en local, ce qui est cohérent avec le positionnement open source. La configuration initiale consiste à pointer l’application vers un ou plusieurs dépôts Git locaux et à renseigner les clés API des modèles utilisés.
[capture: écran d’accueil Kanbots avec sélecteur de dépôts Git locaux et zone de saisie de clé API]
J’ai connecté trois dépôts pour le test : un backend Python (FastAPI, 18 000 lignes), un projet Next.js (12 000 lignes) et un petit utilitaire Go que je maintiens seul. Le premier ticket dispatché — une refonte de la pagination dans le backend Python — a démarré à 22 h 01. Soit 47 minutes entre le téléchargement et le premier agent en exécution. C’est rapide pour un outil de cette catégorie ; comparé à un setup Linear + Claude Code custom, j’aurais mis deux heures.
Détail qui m’a surpris : Kanbots crée systématiquement un git worktree pour chaque agent dispatché. Aucun risque que deux runs simultanés se marchent dessus sur la branche main. Chaque agent vit dans kanbots/issue-N, une convention de nommage simple à filtrer ensuite côté git log.
Test en conditions réelles : 30 tickets dispatchés sur trois dépôts
J’ai voulu mesurer l’outil sur des cas d’usage que je rencontre vraiment, pas sur des exemples synthétiques. J’ai donc puisé dans mon backlog réel et dispatché trente tickets répartis comme suit : douze sur le backend Python, dix sur le projet Next.js, huit sur l’utilitaire Go.
Cas 1 — Audit de sécurité parallèle sur le backend Python
J’ai créé une colonne « Audit » et empilé six cartes, chacune posant une question de sécurité distincte. Deux exemples typés Léo, repris textuellement de l’interface de Kanbots tellement la formulation colle à mon usage quotidien : « which routes don’t have rate limiting? » et « where do we use the old auth helper? », formulations issues du site officiel publié le 1er janvier 2026.
J’ai cliqué « Dispatch all ». Six agents ont démarré en parallèle. Sur mon MacBook Pro M3 (36 Go RAM), la charge CPU est montée à 62 % pendant huit minutes, puis a redescendu progressivement. Les six runs ont rendu leurs verdicts entre 11 et 23 minutes. Aucun crash, aucun blocage.
[capture: board Kanban Kanbots avec six cartes en colonne « En cours », badge coût cumulé à 1,42 $]
Le board s’est mis à jour en temps réel, comme annoncé. Chaque agent affichait son statut (« lecture du repo », « analyse middleware », « rédaction du rapport »), ses décisions intermédiaires, et le coût cumulé du run. Le ticket sur le rate limiting a coûté 0,31 $, celui sur l’auth helper 0,28 $. Sur l’ensemble des six cartes : 1,42 $ pour un audit que j’aurais facturé une demi-journée à un client.
Cas 2 — Refactor Next.js avec dépendances entre cartes
Test plus tendu : dispatcher dix cartes sur le même projet, dont quatre touchant le même module de routing. C’est ici que la mécanique du git worktree montre sa valeur. Chaque agent a travaillé sur sa propre branche kanbots/issue-N, sans aucune interférence à l’exécution. La résolution des conflits se fait après, à la phase de merge, ce qui correspond à un workflow Git classique.
[capture: liste de branches kanbots/issue-12 à kanbots/issue-21 dans le terminal, avec statuts différents]
Sur les dix runs, sept sont passés directement, deux ont rendu un diff que j’ai dû ajuster manuellement, un seul a échoué (l’agent a tourné en boucle sur un import circulaire que j’aurais dû identifier moi-même avant de dispatcher). Taux de réussite brut : 70 %. C’est honnête pour de l’agentique non supervisée sur un projet réel.
Cas 3 — Petits utilitaires Go en série
Sur le projet Go, j’ai dispatché huit cartes simples : ajout de tests, normalisation de logs, mise à jour de dépendances. Les huit runs sont passés sans intervention manuelle. Coût total : 0,84 $. Temps total wall-clock : 14 minutes pour les huit cartes en parallèle, contre une heure trente que j’aurais consacrée à les faire séquentiellement.
C’est le scénario où Kanbots brille le plus : tickets indépendants, petits diffs, validation rapide. Le parallélisme transforme une demi-journée de chores en pause café.
Forces et limites : ce que j’ai aimé, ce qui m’a agacé
J’ai pris des notes au fil de l’eau pendant les 72 heures de test. Voici la synthèse honnête.
Pour :
– Vraie parallélisation : dispatcher six agents simultanés sans collision est l’argument central, et il tient en pratique sur un MacBook M3.
– Worktree par agent : la convention kanbots/issue-N est lisible, propre, compatible avec n’importe quel workflow Git existant.
– Board live : voir les décisions remonter en temps réel évite l’angoisse du « est-ce que ça avance ? ».
– Coûts visibles par carte : chaque ticket affiche son coût LLM cumulé, ce qui aide à arbitrer entre dispatch et travail manuel.
– MIT, gratuit, local : pas de SaaS, pas de vendor lock-in, pas d’envoi de code à un serveur tiers. Comptabilité simple pour mes clients sensibles aux données.
Contre : – Pas d’historique cross-projets agrégé : impossible (à ce stade) de voir d’un coup d’œil mes 30 derniers runs tous dépôts confondus. C’est par projet, point. – Pas de templates de cartes : chaque ticket se rédige à la main. Pour des audits répétitifs, j’aimerais des modèles préfaits. – Documentation encore légère : le site officiel tient en quelques pages, plusieurs concepts (rollback d’un worktree, gestion des secrets par projet) ne sont pas explicités. – Charge CPU notable : six agents en parallèle, c’est 60 % de CPU soutenu. Sur un laptop d’entrée de gamme, ça va chauffer. – Pas de version mobile ni de web : si vous voulez surveiller un run depuis votre téléphone, ce n’est pas pour vous.
Vs la concurrence : Kanbots face à Linear + Claude Code et Aider
J’utilise Linear + Claude Code en custom au quotidien, et Aider pour les sessions de pair-programming. J’ai voulu poser un comparatif objectif.
| Critère | Kanbots | Linear + Claude Code | Aider |
|---|---|---|---|
| Prix | Gratuit (MIT) | Linear 8 $/user/mois + coûts LLM | Open source, coûts LLM seuls |
| Parallélisation native | Oui, par worktree | Non, à scripter soi-même | Non, session interactive |
| Board Kanban intégré | Oui | Oui (Linear) | Non |
| Exécution locale | Oui, 100 % | Linear cloud, Claude Code local | Local |
| Setup initial | ~45 min | ~2 h pour brancher Claude Code | ~15 min |
| Courbe d’apprentissage | Faible | Moyenne (deux outils à connecter) | Faible |
Kanbots se place dans un créneau singulier : il prend l’expérience Kanban de Linear, l’autonomie d’agent d’Aider, et y ajoute la parallélisation native que les deux autres ne proposent pas en standard. Si vous orchestrez régulièrement plus de trois tâches IA simultanées, l’écart de productivité est réel.
En revanche, Linear reste imbattable sur la collaboration multi-utilisateurs et le reporting cross-projets. Aider garde l’avantage sur le dialogue itératif avec le modèle. Kanbots n’essaie pas de remplacer ces outils, il occupe un territoire libre.
Verdict : 7,8 / 10, un Kanban d’agents qui mérite sa place
Note finale : 7,8 / 10.
Kanbots fait une chose, la fait bien, et la fait gratuitement. La parallélisation des agents sur un Kanban local est un cas d’usage que personne d’autre n’adresse aussi proprement. Le choix architectural du git worktree par agent est un signal fort : l’auteur de l’outil connaît les workflows Git réels et n’a pas bricolé sur la branche main.
J’ai déduit 2,2 points pour trois raisons : documentation encore mince, absence de templates de cartes, et pas de vue cross-projets. Tout cela est rattrapable sur les prochaines versions.
En un mot : indispensable si vous lancez plus de trois agents IA par jour. Dispensable si vos workflows IA sont déjà bien posés dans Linear ou GitHub Projects avec des scripts maison.
Pour qui ? – Le développeur solo overbooké qui jongle entre cinq projets et veut paralléliser les chores sans setup complexe. – Le tech lead qui pilote deux ou trois équipes et veut un poste de commande visuel pour les runs d’agents sur ses repos sensibles. – Le freelance qui facture des audits récurrents et cherche à comprimer le wall-clock de ses livrables.
FAQ
Kanbots est-il compatible avec tous les gestionnaires de tickets Kanban existants ?
Non, et c’est une nuance importante. Kanbots n’est pas un connecteur qui se branche sur Jira, Linear ou Trello. C’est une application desktop autonome avec son propre board Kanban. Vous pouvez bien sûr maintenir vos tickets métier dans Linear et ne dispatcher dans Kanbots que les tâches que vous voulez confier à des agents IA, en faisant l’orchestration manuellement.
Existe-t-il une version payante ou premium de Kanbots ?
Non. Selon le site officiel publié le 1er janvier 2026, Kanbots est sous licence MIT, gratuit à vie, sans version premium. Le seul modèle économique mentionné est un système de dons libres « Pay-what-you-can » pour soutenir le projet. Les coûts à votre charge sont uniquement ceux des appels LLM consommés par vos agents (clés API Anthropic, OpenAI, etc.).
Combien coûte un dispatch type sur Kanbots ?
Lors de mon test sur 30 cartes réparties sur trois dépôts, j’ai dépensé environ 4,80 $ de tokens LLM. Le coût varie fortement selon la taille du repo, la complexité du ticket et le modèle utilisé. Les petits chores Go coûtaient 0,10 $ pièce, un audit de sécurité bien posé tournait autour de 0,30 $, et un gros refactor sur un fichier de 800 lignes a grimpé à 0,72 $. Comptez 0,15-0,30 $ par carte en moyenne.
À retenir
Trois enseignements concrets après 72 heures avec Kanbots :
- Productivité réelle : 30 cartes traitées en trois jours pour 4,80 $ de tokens, dont 70 % de réussite directe sur du refactor Next.js.
- Architecture saine : un
git worktreepar agent, branchekanbots/issue-N, zéro collision en cours d’exécution sur les trois dépôts testés. - Modèle économique propre : MIT, gratuit à vie, dons libres, exécution 100 % locale — adapté aux clients qui interdisent l’envoi de code à un SaaS.
À suivre
Trois jalons à surveiller d’ici la fin du second semestre 2026 :
- Documentation : étoffement de la doc officielle, indispensable pour adoption au-delà du cercle des early adopters.
- Templates de cartes : si la roadmap intègre des modèles préfaits (audit sécu, refactor, tests), l’outil double sa valeur pour les freelances.
- Vue cross-projets : un dashboard agrégé multi-dépôts ferait basculer Kanbots du statut « outil de niche » à « cockpit quotidien » pour les tech leads.
Je garde Kanbots installé sur ma machine. C’est le meilleur signal que je puisse donner.
