Alternative à Vibe Kanban : où exécuter vos agents de codage désormais

Vous avez pris l'habitude de travailler autour d'un tableau. Une colonne par tâche, un agent de codage par carte, chacun dans son propre git worktree pour éviter les collisions. Une façon propre de lancer trois ou quatre agents en même temps tout en relisant leurs diffs un par un. Puis l'entreprise qui maintenait l'outil a mis fin à son cloud, et la vraie question s'est posée : où exécuter vos agents de codage désormais, et cette réponse tient-elle au-delà d'un seul ordinateur portable et d'une seule personne ?

Si vous cherchez une alternative à Vibe Kanban, vous ne cherchez pas à remplacer Claude Code ou Codex. Vous cherchez la couche qui entoure ces runtimes : l'endroit qui confie une tâche à chaque agent, isole son travail et vous montre ce qui a changé avant toute fusion. Ce guide passe en revue cette couche. Il reconnaît pleinement à Vibe Kanban le mérite du modèle qu'il a prouvé, marque la ligne exacte où un tableau local s'arrête, et montre comment Sharkly poursuit au-delà de cette ligne, vers des tâches partagées, des Crews et des Sprints pour toute une équipe.

TL;DR

Vibe Kanban a été le précurseur du modèle « un tableau par agent » : exécuter plusieurs agents de codage en parallèle, chacun dans son propre worktree, et relire leur production sur un tableau kanban installé sur votre machine. Sharkly conserve ce modèle et y ajoute la couche équipe : une Tâche partagée, des Ordinateurs connectés, des Crews, des Sprints et une revue humaine de la demande jusqu'à la mise en production. Si vous travaillez seul sur une seule machine, un tableau local suffit. Si une équipe a besoin d'un contexte partagé et d'un point de contrôle avant validation, c'est là que Sharkly prend le relais.

Le problème qu'une alternative à Vibe Kanban résout vraiment

Vibe Kanban a compris quelque chose que la plupart des outils ont manqué. Quand vous lancez plusieurs agents de codage IA en même temps, le plus difficile n'est pas les modèles. Ce sont les collisions. Deux agents qui modifient les mêmes fichiers, des sorties éparpillées dans des onglets de terminal, et aucune vue unique permettant de savoir quelle tâche est terminée, laquelle est bloquée et laquelle a discrètement déraillé.

La réponse du tableau par agent était élégante. Une carte par tâche. Un git worktree dédié à chaque carte, pour que l'agent travaille sur une branche isolée dans un répertoire isolé. Laissez Claude Code, Gemini CLI, Codex ou un autre runtime faire le travail dans ce bac à sable, puis ramenez le diff pour relecture. On passait ainsi de « j'ai cinq agents et aucune idée de ce qu'ils ont fait » à un tableau vraiment lisible. Si les mécanismes de ce fonctionnement en parallèle vous intéressent pour eux-mêmes, notre guide sur comment exécuter plusieurs agents Claude Code en parallèle détaille la mise en place des worktrees.

Le problème n'a jamais été le modèle de fonctionnement. Le problème, c'est ce qu'un tableau local ne peut pas atteindre. Un tableau sur votre machine est un tableau pour vous. Votre collègue ne voit pas la tâche, ne peut pas prendre une carte bloquée, ne peut pas relire le diff avant sa fusion et ne peut pas savoir, depuis l'autre bout du bureau, si le sprint est dans les temps. Quand le travail est solo, tout va bien. Quand il appartient à une équipe, la pièce manquante est un enregistrement partagé — et c'est un autre type d'outil.

Ce que Vibe Kanban a prouvé, dit simplement

Rendons à l'outil sa meilleure version, car il l'a méritée. Vibe Kanban traitait les exécutions d'agents comme des unités de travail à part entière, et non comme des sessions de terminal jetables. Il a fait de l'isolation par worktree le comportement par défaut, si bien que les agents parallèles ont cessé de se marcher sur les pieds. Il a rendu le changement de runtime peu coûteux, pour que vous ne soyez pas marié à un seul modèle. Et il a fait de la revue une véritable étape, et non une réflexion après coup, en plaçant le diff sous vos yeux avant que vous ne fassiez passer une carte en terminé.

Ces quatre idées sont justes, et toute alternative sérieuse doit les conserver toutes. Une alternative à Vibe Kanban qui abandonne l'isolation par worktree, masque le diff ou vous enferme dans un seul runtime est une régression, quoi qu'elle apporte par ailleurs. Le niveau fixé par le tableau est un plancher, pas un plafond.

Ce qui a changé, c'est l'histoire de la maintenance. Le projet est open source et peut toujours fonctionner en local, mais les fonctionnalités cloud opérées par l'entreprise ont été retirées et les correctifs reposent désormais sur des contributeurs de la communauté. Pour un développeur solo, c'est peut-être parfaitement acceptable. Pour une équipe qui mise un trimestre de livraisons sur l'outil, « cela dépend de qui se présente » est un risque bien réel à peser, et c'est la raison honnête pour laquelle l'envie de migrer est bien réelle aujourd'hui.

Là où le tableau local s'arrête et où Sharkly prend le relais

Voici les deux options, formulées telles que le choix se pose réellement.

Optez pour un tableau local si vous êtes seul sur une seule machine, que les tâches ne concernent que vous et que personne d'autre n'a besoin de voir le travail avant l'ouverture d'une pull request. Le dispositif « un tableau par agent » est léger, il tourne là où vous travaillez et n'ajoute aucune surcharge de coordination, puisqu'il n'y a personne avec qui se coordonner. Dans ce cas, se tourner vers une plateforme d'équipe est superflu.

Choisissez Sharkly dès que les exécutions d'agents cessent d'être privées. À l'instant où une deuxième personne doit assigner une tâche, lever un blocage ou relire un diff avant sa fusion, un tableau qui vit sur votre ordinateur portable devient le goulot d'étranglement. C'est là que se situe la ligne. Sharkly est la couche qui entoure les mêmes runtimes que ceux que vous utilisez déjà et qui rend chaque exécution assignable, visible et relisible par l'équipe, et non par vous seul.

Une définition rapide, façon glossaire, car tout ce qui suit en dépend. Une Tâche est l'unité de travail principale dans Sharkly. Elle contient l'objectif, l'Agent assigné, le runtime, l'avancement, les blocages, le diff produit et la revue humaine, le tout dans un seul enregistrement partagé. Là où une carte d'un tableau local vous appartient, une Tâche appartient à l'équipe.

Et une limite, car un lecteur qui migre depuis un tableau risque sinon de se tromper. Sharkly ne remplace pas Claude Code, Codex ou Gemini. Il n'exécute pas le modèle et n'écrit pas le code. Il ajoute la couche de tâche partagée, d'Ordinateur connecté, de contexte, de contrôle et de revue autour des outils d'exécution que votre équipe utilise déjà. Si vous aimiez pouvoir changer de runtime librement avec Vibe Kanban, Sharkly conserve cette liberté et y ajoute une équipe.

Le parcours de migration : gardez vos runtimes, gardez vos dépôts, ajoutez la couche de revue

Le meilleur côté d'un départ d'un tableau en fin de vie, c'est le peu de choses auxquelles il faut renoncer. Vous ne reconstruisez pas votre stack. Vous gardez ce qui fonctionnait et vous ajoutez ce qui manquait.

Gardez vos runtimes. Claude Code, Codex, Gemini CLI, OpenCode, Cline et les autres continuent d'exécuter exactement comme avant. L'usage des modèles passe toujours par les abonnements ou les clés API déjà configurés dans ces outils. Vous apportez votre propre abonnement ; Sharkly ne s'interpose pas entre l'agent et le modèle. Si vous voulez poser le cadre conceptuel de ce que font ces runtimes, notre article explicatif sur ce que le codage agentique signifie pour les équipes de dev en définit les termes.

Gardez vos dépôts et votre habitude des worktrees. Sharkly exécute les agents dans des worktrees isolés sur des Ordinateurs connectés : la même isolation sur laquelle vous comptiez, désormais rattachée à une Tâche partagée plutôt qu'à une carte locale. Frontend, backend, correction de bugs et couverture de tests peuvent avancer en même temps sans se percuter, ce qui est précisément la raison d'être du modèle « un tableau par agent ».

Ajoutez la couche de revue qui vous manquait. C'est la nouveauté. L'exécution, les blocages, les résultats et les échanges de suivi reviennent dans la chronologie de la Tâche, là où l'équipe peut les voir. Un Agent fait les recherches, exécute, teste et rend compte. Les personnes donnent la direction, accordent l'autorité et acceptent le résultat. L'automatisation s'arrête là où le jugement de l'équipe est requis, puis restitue une livraison avec un contexte complet et des preuves vérifiables. Cette dernière phrase est le contrat qu'un tableau local ne pouvait pas imposer, faute d'équipe de l'autre côté.

La migration est donc additive. Connectez un Ordinateur, pointez Sharkly vers les runtimes que vous avez déjà et commencez à router le travail sans reconstruire un processus que votre équipe maîtrise déjà. Le tableau vous a appris à exécuter des agents en parallèle. Sharkly y fait entrer le reste de l'équipe.

Du tableau solo au système d'équipe : Crews, Sprints et Projets

Une fois les exécutions partagées, trois capacités s'ouvrent, qu'un tableau mono-utilisateur ne pouvait pas offrir.

Les Crews, pour le travail qui mobilise plus d'un agent. Un Crew est un groupe réutilisable de Personnes et d'Agents coordonné par un Agent chef de file. Pour un travail petit et bien délimité, inutile d'en créer un : assignez la Tâche à un seul Agent et gardez zéro pièce mobile. Utilisez un Crew quand l'Agent chef de file doit interpréter un objectif plus large, mobiliser d'autres Agents membres et ramener leurs résultats dans une seule Tâche. C'est la règle honnête. Un Crew est un levier quand le travail comporte réellement plusieurs volets, et un poids mort dans le cas contraire.

Sprints et Projets, pour un suivi qui survit au-delà d'une carte. Un tableau local montre les tâches que vous avez devant vous aujourd'hui. Un Sprint suit l'achèvement, la responsabilité, les dépendances, les changements de périmètre et les blocages sur un ensemble de travail, dans la durée. Pour une équipe hybride de Personnes et d'Agents, c'est la différence entre « les agents ont fait des trucs cette semaine » et un plan sur lequel on peut réellement rendre des comptes. Notre introduction à l'orchestration d'agents IA pour les équipes de dev explique pourquoi c'est la couche de coordination, et non les modèles, qui fait gagner ou perdre le débit d'une équipe.

La transparence d'équipe, par défaut plutôt que par partage d'écran. Gardez le contexte, l'avancement, les blocages, les résultats et la revue humaine visibles de la demande jusqu'à la mise en production. Sur un tableau local, la visibilité s'arrêtait à votre écran. Dans un système partagé, le levier ne vient pas de l'ouverture de plus de conversations IA. Il vient du partage des rôles, des règles, du contexte et des workflows, pour qu'une bonne configuration devienne une capacité réutilisée par toute l'équipe.

Vibe Kanban vs Sharkly : une comparaison honnête

Lisez ce tableau comme une répartition des rôles, pas comme un classement. Pour un développeur solo qui veut un tableau local gratuit et rien de plus, le projet maintenu par la communauté reste peut-être le bon choix, et il n'y a aucune honte à y rester. Pour une équipe qui a besoin d'exécutions partagées, assignables et relisibles, le tableau allait de toute façon manquer de place, et c'est avec Sharkly que les mêmes runtimes continuent de fonctionner, équipe comprise. Vous pouvez télécharger Sharkly et connecter un Ordinateur pour voir la différence sur du vrai travail.

Les erreurs fréquentes quand on quitte un tableau local

• Le voir comme un simple remplacement à l'identique. Vous ne cherchez pas un autre tableau. Vous cherchez la couche d'équipe que le tableau n'a jamais eue. Si l'alternative ne fait que reproduire des colonnes et des cartes, elle n'a rien résolu.
• Abandonner l'isolation par worktree pour aller plus vite. C'est cette isolation qui évite que les agents parallèles entrent en collision. Gardez-la. Tout outil qui oblige les agents à partager un répertoire de travail réintroduit un vrai problème.
• Créer un Crew pour un travail à un seul agent. Ne recourez à un Crew que lorsque l'objectif exige vraiment un Agent chef de file pour coordonner des membres. Pour une tâche bien délimitée, un seul Agent et zéro pièce mobile est la bonne réponse.
• Sauter l'étape de revue pour se sentir productif. Le but de cette couche est que des personnes acceptent le résultat. Fusionner des diffs d'agents sans relecture parce que c'est plus rapide revient à sacrifier exactement la sécurité que tout le système est censé apporter.
• Tout migrer dès le premier jour. Commencez par une vraie exigence et une Tâche à faible risque. Prouvez la boucle, puis élargissez-la.

Conclusion

Vibe Kanban a prouvé un modèle qui mérite d'être conservé : les agents donnent leur meilleur en parallèle, isolés dans leurs propres worktrees, avec une revue érigée en véritable étape. Ce modèle est désormais le plancher, et toute alternative à Vibe Kanban qui l'abandonne recule.

• Le modèle « un tableau par agent » était juste ; des agents parallèles, isolés par worktree, avec relecture des diffs, c'est la bonne forme.
• Un tableau local s'arrête à une personne sur une machine. Un travail partagé exige un enregistrement partagé.
• Sharkly conserve vos runtimes, vos dépôts et votre habitude des worktrees, et ajoute autour d'eux la couche d'équipe.
• Une Tâche réunit au même endroit l'objectif, le runtime, l'avancement, les blocages, le diff et la revue.
• Les Crews, les Sprints et les Projets transforment des exécutions parallèles en un plan sur lequel une équipe peut rendre des comptes.
• Les Agents font les recherches, exécutent, testent et rendent compte ; les personnes donnent la direction, accordent l'autorité et acceptent le résultat.

Si vous choisissez maintenant où exécuter vos agents de codage, gardez les outils que votre équipe utilise déjà et ajoutez la couche qui rend les exécutions assignables et traçables. Connectez un Ordinateur, créez un Agent et confiez-lui une tâche ennuyeuse. Puis laissez le reste de l'équipe regarder le travail revenir dans la Tâche. Commencez sur Sharkly, et la documentation approfondit chaque concept sur docs.sharkly.ai.

FAQ

Vibe Kanban est-il encore utilisable après l'arrêt de Bloop ? Oui. Le projet est open source et peut toujours fonctionner en local. Les fonctionnalités cloud opérées par l'entreprise ont été retirées, et les correctifs comme les mises à jour dépendent désormais de contributeurs de la communauté. Pour un usage solo, cela peut convenir ; pour une équipe qui s'appuie dessus pour livrer, le risque de maintenance mérite d'être pesé.

Sharkly remplace-t-il Claude Code ou Codex ? Non. Sharkly ne remplace ni Claude Code, ni Codex, ni les autres outils d'exécution. Ce sont ces runtimes qui exécutent. Sharkly ajoute autour d'eux la couche de tâche partagée, d'Ordinateur, de contexte, de contrôle et de revue. Vous continuez d'utiliser les mêmes agents.

Dois-je renoncer à exécuter des agents dans des worktrees parallèles ? Non. Sharkly exécute les agents dans des worktrees isolés sur des Ordinateurs connectés, la même isolation sur laquelle reposait le modèle « un tableau par agent ». Frontend, backend et tests peuvent avancer en même temps sans se percuter. Voir comment exécuter plusieurs agents Claude Code en parallèle pour le fonctionnement sous-jacent.

En quoi consiste concrètement la migration depuis un tableau local ? Gardez vos runtimes et vos dépôts. Connectez un Ordinateur, pointez Sharkly vers les outils d'exécution que vous utilisez déjà et commencez à router le travail sous forme de Tâches partagées. L'usage des modèles passe toujours par les abonnements ou les clés API déjà configurés dans ces outils, donc la facturation ne change pas.

Quand ne faut-il pas utiliser Sharkly ? Quand vous êtes seul sur une machine et que personne d'autre n'a besoin de voir ou de relire le travail, un tableau local suffit. Sharkly gagne sa place dès qu'une deuxième personne doit assigner, prendre en charge ou relire une exécution d'agent.

Quelle différence entre une carte et une Tâche ? Une carte sur un tableau local vous appartient et vit sur votre machine. Une Tâche est l'enregistrement partagé de l'équipe : elle contient l'objectif, l'Agent assigné, le runtime, l'avancement, les blocages, le diff et la revue humaine, et les résultats d'exécution y reviennent.