Claude Squad vs Conductor vs tmux : configurations d’agents DIY

Vous avez commencé par lancer deux agents de code en parallèle parce qu'un seul était trop lent. Aujourd'hui vous en faites tourner cinq, et le plus difficile n'est pas de les démarrer. C'est de se rappeler quel terminal héberge quel agent, ce que chacun a modifié, quelle branche peut être fusionnée sans risque, et si celui qui est devenu silencieux il y a quarante minutes a terminé ou s'est bloqué. Le parallélisme, c'était la partie facile. Le suivi, c'est l'impôt que vous payez chaque jour ensuite.

C'est cet impôt que les outils d'agents parallèles faits maison tentent d'alléger. Conductor, Claude Squad et les scripts tmux + git worktree bricolés à la main résolvent tous le même problème initial : donner à chaque agent son propre espace de travail isolé pour que plusieurs exécutions avancent en même temps sans se marcher sur les fichiers. Ils le font bien, et pour un développeur solo sur une seule machine, ils peuvent suffire. Voici un tour d'horizon honnête de ce que fait chacun, où chacun s'arrête, et la limite où la gestion de fenêtres devient discrètement un problème d'équipe.

C'est à cette limite qu'intervient Sharkly, et c'est le flux de travail que cet article vous fait parcourir. Sharkly ne remplace ni Claude Code, ni Codex, ni aucun runner fait maison. C'est la couche partagée de Tâches, d'Ordinateurs, de contexte et de revue autour des outils que vous utilisez déjà, pour que le travail des agents reste visible de la demande à la livraison au lieu de disparaître dans des terminaux privés. Si votre configuration tient encore sur un écran, gardez-la. Si elle a cessé de tenir il y a des semaines, la seconde moitié de cet article est pour vous.

TL;DR

Conductor, Claude Squad et tmux brut plus git worktrees sont trois façons de faire tourner plusieurs agents de code IA en parallèle sur votre propre machine. Conductor est une application Mac gratuite conçue pour des exécutions locales en solo. Claude Squad est une application terminal multiplateforme qui ajoute un sélecteur par-dessus les sessions tmux et les git worktrees. Tmux brut plus des scripts worktree vous donnent un contrôle total et zéro abstraction. Tous les trois maîtrisent l'exécution parallèle. Aucun n'a été conçu pour offrir à une équipe une visibilité partagée, une revue ou des transferts, et c'est exactement le point où vous passez à une couche d'orchestration comme Sharkly.

Le vrai goulot d'étranglement n'est pas le parallélisme

L'isolation est un problème résolu. Un git worktree permet à un dépôt d'extraire plusieurs branches dans des répertoires séparés simultanément, de sorte que chaque agent modifie sa propre copie du code et commite sur sa propre branche. Pas d'arbre de travail partagé, pas de diffs à moitié appliqués qui entrent en collision. Tous les outils de cette comparaison reposent sur cette même primitive. Si vous voulez les mécanismes en détail, notre guide sur les git worktrees avec les agents de code IA couvre les commandes et les pièges.

Alors si l'isolation est gratuite, pourquoi gérer plusieurs agents reste-t-il chaotique ? Parce que le travail produit par un agent doit aboutir quelque part où un humain peut le trouver, le lire, le juger et agir dessus. Sur une seule machine, ce « quelque part » c'est votre mémoire à court terme plus un tampon de défilement. Ça tient avec deux agents. Ça s'effiloche à cinq. Ça casse dès qu'une deuxième personne a besoin de savoir ce que vos agents ont fait.

Voici la distinction qui compte. Faire tourner des agents en parallèle est un problème d'exécution : lancer le processus, lui donner un répertoire isolé, le laisser travailler. Réviser et coordonner ce qu'ils produisent est un problème de flux de travail : où vit le résultat, qui l'accepte, que se passe-t-il pour ceux qui calent. Les outils faits maison excellent sur le premier problème. Les trois sections ci-dessous jugent chacun selon ses propres termes, puis nous examinerons ce qui arrive au second problème à mesure que votre configuration grandit.

Conductor : l'application Mac gratuite pour des exécutions parallèles en solo

Conductor est une application de bureau Mac native pour faire tourner plusieurs agents Claude Code côte à côte. Vous la pointez vers un dépôt, décrivez une modification, et elle lance chaque exécution dans son propre espace de travail adossé à un git worktree. Au lieu de jongler avec des onglets de terminal, vous obtenez une vue en fenêtres : une colonne par agent, chacune avec sa propre conversation, son diff et son statut. Vous passez de l'une à l'autre comme vous passeriez d'un chat à l'autre.

Ce qu'elle fait bien, c'est éliminer la comptabilité de terminaux pour une seule personne. Vous ne tapez aucune commande tmux. Vous ne vous souvenez pas quel volet correspond à quoi. L'application suit les worktrees, affiche les diffs dans un vrai visualiseur de diff, et vous permet de sauter d'un agent à l'autre sans perdre le fil. Pour un développeur solo sur Mac qui veut faire tourner trois ou quatre sessions Claude Code sur une même base de code et rester sain d'esprit, c'est une réponse propre et fluide. Le téléchargement est gratuit, et il n'y a rien à configurer côté serveur puisqu'il n'y a pas de serveur.

Les limites sont le revers de ces atouts. Conductor est réservé à macOS, donc un collègue sous Linux ne peut pas partager votre configuration. Il est bâti autour de Claude Code comme exécution plutôt qu'un mélange d'agents. Et c'est une application de bureau mono-utilisateur : les espaces de travail, les diffs et les décisions vivent sur votre Mac. Un autre ingénieur ne peut pas ouvrir votre Conductor pour voir ce que font vos agents, et il n'existe aucun registre partagé de qui a accepté quelle modification. Ce n'est pas un défaut. C'est un périmètre. Conductor est un cockpit pour un seul pilote.

Utilisez Conductor quand vous êtes un développeur solo sur Mac faisant tourner Claude Code et que vous voulez le chemin le plus rapide de « beaucoup de terminaux » à « une seule fenêtre sereine ». Tournez-vous vers autre chose quand une deuxième personne doit voir, réviser ou reprendre l'une de ces exécutions.

Claude Squad : tmux et worktrees avec une interface texte par-dessus

Claude Squad est une application terminal open source qui gère plusieurs agents dans des espaces de travail isolés. Sous le capot, elle fait ce qu'un ingénieur méticuleux scripterait à la main : elle crée un git worktree par agent et exécute chaque agent dans sa propre session tmux, puis ajoute une interface texte par-dessus pour lister vos agents, passer dans l'un d'eux et voir lesquels travaillent, attendent ou ont terminé. Elle est multiplateforme, fonctionne sur macOS et Linux, et n'est pas liée à une seule exécution. Elle peut piloter Claude Code, Codex, Aider et d'autres agents en ligne de commande, ce qui en fait un favori des développeurs qui mélangent les outils. Le code source se trouve dans le dépôt Claude Squad sur GitHub.

Son attrait, c'est qu'elle vous offre l'ergonomie d'un vrai outil sans masquer les primitives auxquelles vous faites confiance. Vous gardez les worktrees et tmux, donc rien n'est magique et tout est inspectable, mais vous cessez d'écrire la colle à la main. Lancer un nouvel agent est une frappe, pas un rituel en trois commandes. Mettre un agent en pause libère ses ressources et préserve sa branche. Si vous vivez déjà dans le terminal et voulez une flotte d'agents dans laquelle naviguer par onglets, Claude Squad atteint un point d'équilibre que les scripts bruts et les applications de bureau ratent tous les deux. Notre tutoriel sur comment faire tourner plusieurs agents Claude Code en parallèle montre ce même schéma tmux + worktree qu'elle automatise.

Ses limites sont celles du terminal dans lequel elle vit. L'état est local à votre machine et à votre shell. Quand vous fermez la session, la vue partagée se ferme avec elle. Il n'y a pas de chronologie qu'un manager peut ouvrir, pas d'endroit où un relecteur qui n'est pas vous peut accepter ou refuser une modification, pas de file dans laquelle un collègue peut piocher la tâche suivante. Claude Squad est un excellent centre de commande pour un seul opérateur. Elle n'a jamais cherché à être le système de référence d'une équipe, et le lui demander revient à solliciter le mauvais outil.

Utilisez Claude Squad quand vous êtes un développeur adepte du terminal faisant tourner un mélange d'agents sur une machine et que vous voulez un sélecteur rapide sans renoncer aux worktrees et à tmux. Tournez-vous vers autre chose quand les exécutions doivent être assignables à d'autres personnes ou révisables par quelqu'un qui n'est pas assis à votre clavier.

Tmux brut plus git worktrees : les scripts que vous possédez

La configuration maison la plus honnête est aussi la plus ancienne : quelques scripts shell qui créent des worktrees et ouvrent des fenêtres tmux, une par agent. Ça ressemble à ceci.

# one worktree and one branch per parallel unit of work
git worktree add ../app-auth    -b feature/auth
git worktree add ../app-billing -b feature/billing

# a named tmux window per agent, launched in its worktree
tmux new-window -n auth    -c ../app-auth    'claude'
tmux new-window -n billing -c ../app-billing 'claude'

Deux commandes par fonctionnalité et vous avez des agents isolés tournant en parallèle, chacun sur sa propre branche, chacun dans une fenêtre étiquetée vers laquelle vous pouvez basculer d'une frappe. Enrobez-le dans une boucle et vous pouvez en lancer une douzaine. Rien ne s'interpose entre vous et les outils. Vous pouvez lire chaque ligne, modifier n'importe quoi, et ça ne coûte que le temps de l'écrire.

Pour un certain type de développeur, c'est la bonne réponse pour toujours, et ça mérite le respect plutôt qu'on cherche à l'en dissuader. Vous comprenez exactement ce qui s'exécute parce que vous l'avez écrit. Pas de fournisseur, pas de mise à jour qui casse votre flux, pas d'abstraction qui fuit au mauvais moment. Si vos besoins sont stables et personnels, les scripts que vous possédez battent les outils que vous louez.

Le coût apparaît à mesure que votre configuration grandit, et il apparaît sous forme de maintenance, pas de fonctionnalités. Le nettoyage vous incombe : les worktrees obsolètes s'accumulent jusqu'à ce que git worktree prune et un balayage tmux kill-session fassent partie de votre routine. Les collisions de noms vous incombent. Un agent qui plante laisse une fenêtre morte et une branche à moitié terminée, et le remarquer vous incombe. Et rien de tout cela ne quitte votre machine, donc dès qu'un collègue demande « qu'ont livré tes agents cette semaine », la seule réponse vit dans votre historique de défilement. Les scripts augmentent votre débit. Ils n'augmentent pas votre capacité à partager le résultat.

Utilisez tmux brut et les scripts worktree quand vous voulez un contrôle total, que vous aimez posséder votre outillage, et que le public du travail c'est vous. Tournez-vous vers autre chose quand vous vous surprenez à reconstruire du suivi de statut, du nettoyage et de la logique de transfert qui commence à ressembler à un produit que vous n'aviez pas l'intention d'écrire.

Comparaison : ce que chaque configuration maison fait bien

Les deux dernières lignes ne sont pas une critique. C'est le schéma d'ensemble. Chacun de ces outils est conçu pour un seul opérateur sur une seule machine, et dans ce périmètre, ils vont de bons à excellents. La colonne vide est la même pour les trois, et c'est la colonne qui compte le jour où le travail cesse de n'être que le vôtre. Pour une cartographie plus large de la catégorie, consultez notre aperçu de l'orchestration d'agents IA.

La ligne de passage : quand la gestion de fenêtres cesse d'être le problème

Voici le signe révélateur. Vous cessez de demander « comment faire tourner plus d'agents à la fois » et vous commencez à poser des questions auxquelles les outils faits maison ne peuvent pas répondre :

• Les modifications de lesquels de mes agents ont été révisées par quelqu'un ?
• Si je suis malade, un collègue peut-il voir ce qui est en cours et le reprendre ?
• Où se trouve le registre expliquant pourquoi nous avons accepté ce diff et rejeté cet autre ?
• Quelles exécutions sont bloquées, sur quoi, et depuis combien de temps ?

Ce sont des questions de flux de travail, pas d'exécution. Aucun sélecteur plus performant ou visualiseur de diff plus élégant n'y répondra, parce que la pièce manquante n'est pas sur votre écran. C'est un endroit partagé où le travail peut vivre. C'est la ligne de passage : le jour où votre goulot d'étranglement se déplace de la gestion de fenêtres vers la gestion de la visibilité, de la revue et des transferts.

Sharkly est conçu pour l'autre côté de cette ligne. Il garde le contexte, la progression, les blocages, les résultats et la revue humaine visibles de la demande à la livraison, dans un flux de travail partagé plutôt que dispersé dans des terminaux privés. La répartition des rôles est délibérée : Claude Code, Codex et les outils similaires assurent l'exécution ; Sharkly gère l'assignation au niveau de l'équipe, les Ordinateurs connectés, le contexte des tâches, la progression, les blocages, les résultats et la revue humaine à travers ces outils. Vous gardez les exécutions et les worktrees auxquels vous faites déjà confiance. Vous ajoutez la couche qui permet à plus d'une personne de voir et d'orienter le travail.

La garantie compte autant que le mécanisme. Adopter Sharkly ne vous demande pas de reconstruire votre processus ni d'abandonner vos outils. Vous apportez votre propre abonnement : l'utilisation des modèles continue via les abonnements ou clés API configurés dans les outils que votre équipe utilise déjà. Vous connectez un Ordinateur, pointez Sharkly vers les mêmes dépôts, et commencez à router le travail sans rien démonter. Si vous comparez cela à un tableau local, notre article sur l'alternative à Vibe Kanban couvre le même chemin consistant à garder ce que vous avez.

À quoi ressemble le même flux parallèle dans Sharkly

Les outils faits maison donnent à chaque agent un worktree et une fenêtre. Sharkly donne à chaque unité de travail une Tâche, et laisse les Agents l'exécuter dans des worktrees isolés de la même manière, avec une différence : le résultat revient à la Tâche au lieu de rester dans votre historique de défilement.

Une Tâche est l'unité de travail principale dans Sharkly. Elle porte l'objectif, le périmètre, le diff, la discussion et la revue dans un seul registre partagé. Quand vous assignez une Tâche à un Agent, l'Agent la prend en charge, travaille dans son propre worktree isolé, lance le typecheck, les tests et le build, puis rattache le résumé des modifications, les résultats de vérification et les limites connues à cette Tâche. La personne suivante qui regarde n'a pas besoin de votre terminal. Elle ouvre la Tâche.

La plus petite version utile est délibérément ennuyeuse. Connectez un Ordinateur, créez un Agent et assignez-lui une Tâche à faible risque, exactement comme notre tutoriel pour la première tâche la met en place. De là, l'histoire parallèle s'étend comme vos scripts le souhaitaient : plusieurs Agents prennent des Tâches prêtes et travaillent en même temps, chacun isolé, tandis que le frontend, le backend, la correction de bugs et la couverture de tests avancent en parallèle. La différence avec un mur de fenêtres tmux, c'est que chaque exécution est assignable à une personne, révisable par quelqu'un d'autre que vous, et traçable après coup.

Le contrat humain-agent est là où la couche de revue justifie son existence. Les Agents recherchent, exécutent, testent et rendent compte. Les humains 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, et renvoie une livraison avec un contexte complet et des preuves inspectables. Une configuration maison peut faire tourner les agents. Elle ne peut pas tenir ce contrat, parce qu'elle n'a aucun endroit partagé où une personne autre que vous peut accepter ou refuser. Si vous voulez les mécanismes de ce point de contrôle, notre note sur les agents en arrière-plan de Cursor parcourt un flux de revue similaire.

Exemple concret, dans la forme qu'utilisent les équipes. Une tâche comme SH-312 dit « ajouter une limitation de débit à l'API publique ». Un Agent cadre le périmètre, travaille dans son worktree, lance les tests, et renvoie un résumé plus le diff à la Tâche. Votre relecteur ouvre SH-312, lit les preuves, et accepte ou demande des modifications. Quand vous étiez solo, toute cette boucle vivait dans votre tête et un seul terminal. Maintenant elle vit quelque part que l'équipe peut voir, ce qui est tout l'intérêt du passage.

Qui doit rester, qui a dépassé le stade

Une comparaison qui ne fait que pousser vers le haut n'est pas honnête, alors voici la version simple. Beaucoup de gens ne devraient pas changer, et les outils ci-dessus sont le bon foyer pour eux.

• Restez sur Conductor si vous êtes un développeur solo sur Mac qui veut des exécutions Claude Code parallèles dans une fenêtre sereine et que personne d'autre n'a besoin de les voir. Il fait ce travail proprement et n'exige rien d'un serveur.
• Restez sur Claude Squad si vous vivez dans le terminal, faites tourner un mélange d'exécutions, et voulez un sélecteur rapide par-dessus les worktrees et tmux pour votre propre travail. C'est un solide centre de commande pour un seul opérateur.
• Restez sur tmux brut et les scripts worktree si vous valorisez le contrôle total, que votre flux de travail est stable et que vous êtes le seul public de la sortie. Un outillage que l'on possède bat un outillage que l'on loue quand les besoins sont personnels.
• Passez à Sharkly quand le travail a cessé de n'être que le vôtre : quand un collègue doit réviser une exécution, quand quelqu'un doit prendre le relais pendant votre absence, quand un manager doit voir ce qui est bloqué, ou quand vous remarquez que vous reconstruisez le statut et la logique de transfert à la main. Notre aperçu de l'orchestration cartographie où les couches se rejoignent.

Le couple de décision pour toute la catégorie est court. Utilisez un outil fait maison quand la contrainte est votre propre machine et votre propre temps. Utilisez une couche d'orchestration quand la contrainte est la compréhension partagée par votre équipe de ce que les agents ont fait. La plupart des développeurs commencent à gauche et basculent la semaine où le nom d'une deuxième personne apparaît sur le travail.

Scénarios concrets

Le bâtisseur solo qui reste en place. Un développeur freelance livre des fonctionnalités client avec trois ou quatre agents Claude Code sur un Mac. Conductor ou Claude Squad est la réponse complète, et ajouter une couche d'équipe serait du poids sans bénéfice. Rester est le bon choix.

L'équipe de deux qui vient de franchir la ligne. Un fondateur et un premier ingénieur faisaient chacun tourner leurs propres scripts tmux. Aucun ne pouvait réviser le travail d'agent de l'autre sans partage d'écran. Déplacer les exécutions vers des Tâches partagées dans Sharkly a permis à chacun d'ouvrir le diff de l'autre, de l'accepter et de fusionner, sans changer les exécutions que l'un ou l'autre utilisait déjà.

Le lead qui standardise une squad. Un lead technique avec cinq ingénieurs a constaté que chacun avait un script worktree légèrement différent et aucune revue partagée. Des Agents partagés et un flux de Tâches commun ont transformé cinq configurations privées en un flux de travail réutilisable par l'équipe, tandis que chaque ingénieur gardait son propre Ordinateur et son propre abonnement de modèle.

FAQ

Quelle est la différence entre Claude Squad et Conductor ? Claude Squad est une application terminal multiplateforme qui gère des agents via tmux et des git worktrees et prend en charge plusieurs exécutions. Conductor est une application de bureau macOS centrée sur l'exécution de Claude Code dans une interface en fenêtres. Les deux isolent chaque exécution dans son propre worktree ; la différence tient au terminal contre l'application native, et au multiplateforme contre le Mac uniquement.

Ai-je besoin de Claude Squad ou Conductor si j'utilise déjà des git worktrees ? Pas nécessairement. Les deux ne sont que des commodités par-dessus la même primitive worktree. Si vous êtes à l'aise pour écrire quelques commandes tmux et git worktree, les scripts bruts vous donnent la même isolation avec plus de contrôle. Les outils vous achètent de l'ergonomie et du nettoyage, pas une nouvelle capacité.

Ces outils faits maison peuvent-ils gérer la revue en équipe ? Non, et ils ne prétendent pas le faire. Conductor, Claude Squad et les scripts tmux gardent tous l'état sur une seule machine pour un seul opérateur. La revue partagée, l'acceptation par une autre personne et un registre durable des décisions sont des fonctionnalités de flux de travail qui vivent dans une couche d'orchestration, pas dans un runner local. Voir notre article sur l'alternative à Vibe Kanban pour cette distinction.

Sharkly remplace-t-il Claude Code ou Claude Squad ? Non. Sharkly ne remplace ni Claude Code, ni Codex, ni les autres outils d'exécution. Il ajoute la couche partagée de Tâches, d'Ordinateurs, de contexte, de contrôle et de revue autour des outils que votre équipe utilise déjà. Vous gardez vos exécutions et vos worktrees et gagnez en plus une visibilité au niveau de l'équipe.

Passer à Sharkly signifie-t-il renoncer aux git worktrees ? Non. Sharkly exécute aussi les Agents dans des worktrees isolés, donc l'isolation sur laquelle vous comptez reste. Ce qui change, c'est où va le résultat : il revient à une Tâche partagée au lieu d'un tampon de terminal privé.

Comment conserver mon utilisation de modèle et mes coûts quand je change ? Vous apportez votre propre abonnement. L'utilisation des modèles continue via les abonnements ou clés API configurés dans les outils que votre équipe connecte, et le quota de modèles dépend de ces outils, forfaits et comptes API. Sharkly ajoute la couche de coordination, pas une nouvelle relation de facturation.

Prêt à franchir la ligne ? Téléchargez Sharkly, connectez un Ordinateur, et assignez une vraie exigence à un seul Agent. Gardez les exécutions et les worktrees auxquels vous faites déjà confiance, et laissez le travail commencer à revenir dans un endroit que toute votre équipe peut voir. La documentation approfondit chaque concept sur docs.sharkly.ai.