Singularity vs Conductor : piloter ses agents par workspace ou par ticket

Conductor est une application Mac pour les développeurs qui utilisent Claude Code ou Codex au quotidien et veulent en lancer plusieurs à la fois. Chaque tâche obtient son workspace, avec sa branche, ses fichiers, son terminal et son diff, et le parcours se termine par une pull request GitHub. L’outil vise surtout les équipes dont la revue passe déjà par GitHub.

Singularity partage la mécanique de base (un agent, un worktree, une branche) mais la place sous un board Kanban : le ticket est la mission de l’agent, avec dépendances, sous-tickets, compte rendu et revue fichier par fichier, puis une intégration locale par rebase. Le choix porte donc sur la façon de piloter : une liste de workspaces qui aboutissent à des PR, ou une file de tickets qui s’intègrent dans un ordre maîtrisé.

Comparatif vérifié le 10 octobre 2026 à partir de la documentation officielle de Conductor et de celle de Singularity. Il compare des workflows, sans benchmark de vitesse ni de qualité du code généré. Tarifs publics en USD/EUR tels qu’affichés, hors taxes et consommation des fournisseurs d’IA ; ils peuvent évoluer.

En bref

• Même isolation : un worktree Git et une branche par tâche, et des agents CLI qui utilisent vos propres comptes.
• Conductor est centré sur le workspace et la PR : départ depuis une issue GitHub ou Linear, diff viewer commenté, onglet Checks, workspaces cloud et collaboration en offre payante.
• Singularity est centré sur le ticket : dépendances, sous-tickets, planificateur, compte rendu, revue fichier par fichier, rebase et file de commits.
• Plateformes : Conductor est réservé à macOS (plus une app iOS) ; Singularity publie des paquets macOS, Windows et Linux.
• Prix : workspaces locaux gratuits chez Conductor, cloud dès 50 USD par mois ; application Singularity gratuite, seule la licence des plugins payants est facturée.

Présentation de Conductor

Sur son site officiel, Conductor se présente comme une application Mac qui crée des agents Claude Code, Codex et Cursor en parallèle dans des workspaces isolés ; sa documentation ajoute OpenCode. Chaque workspace est une copie du projet créée avec des worktrees Git, sur une nouvelle branche partant du dernier commit distant de la branche de base. Un dossier .context accueille notes et passations sans être commité. Les agents tournent sur votre Mac avec vos permissions, et la documentation précise que cette isolation n’est pas une frontière de sécurité. Plusieurs agents peuvent aussi partager un même workspace (agents parallèles).

Les scripts setup, run et archive se définissent dans l’application ou dans .conductor/settings.toml. Conductor réserve dix ports par workspace via CONDUCTOR_PORT, et un mode non concurrent évite les collisions quand le projet dépend d’un port fixe ou d’une base locale (scripts).

Le flux documenté part d’une branche, d’une PR, d’une issue GitHub ou d’une issue Linear. Vous discutez avec l’agent (avec un mode Plan si besoin, voir les modes d’agent), demandez une revue par agent, relisez dans le diff viewer où des commentaires de ligne repartent vers l’agent, puis créez la PR, dont l’agent rédige la description (revue et fusion). L’onglet Checks réunit CI, fils de revue GitHub et todos, et peut décourager une fusion tant que du travail requis reste ouvert.

L’installation exige GitHub (gh auth status) et au moins un fournisseur d’agent ; Conductor n’est pas encore disponible pour Windows ni Linux. Le journal des modifications montre un rythme soutenu : version 0.90.0 du 2 octobre 2026 avec Conductor pour iOS, connexion avec ChatGPT, édition directe dans les diffs ou serveur MCP Conductor. Côté tarifs : Free à 0 USD pour les workspaces locaux avec vos abonnements et clés ; Pro à 50 USD par mois avec workspaces cloud (sandboxes Vercel), collaboration jusqu’à cinq utilisateurs Pro, API et application mobile ; Teams à 60 USD par utilisateur et par mois ; Enterprise sur devis. Le calcul cloud n’est pas facturé en plus pour l’instant, mais une tarification à l’usage est annoncée.

Singularity en quelques mots

Singularity est un ADE (Agentic Development Environment) de bureau édité par Meteor Factory : éditeur avec serveurs de langage, terminaux natifs, client Git (graphe, diffs, remise, worktrees), espaces de travail multi-projets et board Kanban qui sert de surface d’exécution aux agents. Un ticket porte la description, la priorité, les dépendances et la configuration de l’agent ; le board montre le statut et l’activité en direct, et le ticket conserve le compte rendu, les blocages et une résolution courte.

En mode worktree, chaque exécution travaille dans son propre worktree Git ; les commits sont rejoués sur la base par rebase, une file d’intégration ordonne les tickets d’un projet, et le résultat est intégré automatiquement ou attend dans l’onglet Revue. Singularity pilote sept fournisseurs via leurs CLI (Claude Code, Codex, Copilot, Cursor, Gemini, Mistral, Ollama) avec vos comptes ; l’orchestration détaille le cycle d’un agent. L’application est gratuite ; la Singularity Licence (24 € par mois et par poste, essai de 14 jours) débloque seulement les plugins payants du Marketplace, comme Pipelines. Logiciel propriétaire, disponible sur macOS, Windows et Linux (installation).

Tableau comparatif

Une même fonctionnalité dans les deux outils

Prenons un export CSV des factures : un endpoint côté serveur, puis un bouton côté client qui l’appelle.

Dans Conductor, vous partez par exemple d’une issue Linear et créez un workspace pour l’endpoint, un autre pour le bouton. Le script setup installe les dépendances et chaque workspace dispose de sa plage de ports. Vous pouvez demander un plan avant toute modification. La documentation ne décrivant pas de dépendance formelle entre workspaces, l’ordre est à votre charge : contrat d’API dans la consigne, ou attente de la fusion de l’endpoint. Chaque workspace se termine par une revue, une PR, des checks au vert, une fusion puis l’archivage.

Dans Singularity, le ticket « bouton » est marqué Bloqué par le ticket « endpoint ». Le planificateur lance l’endpoint, attend son intégration, puis démarre le bouton sur une base qui contient déjà l’API. La carte affiche la phase de l’agent ; une question bloquante met le ticket en attente jusqu’à votre réponse ; l’agent termine par un compte rendu. Fusion automatique désactivée, vous approuvez chaque fichier, annotez ou relancez avec votre retour, puis l’intégration se fait par rebase.

Dans les deux outils, la réussite dépend d’abord de la consigne et des tests. Conductor vous mène jusqu’à la PR et la CI distante ; Singularity jusqu’à une branche de base à jour, ticket par ticket.

Suivi, revue et intégration

Chez Conductor, l’unité visible est le workspace : il naît d’une branche, d’une PR ou d’une issue, vit dans la barre latérale puis part dans l’historique une fois archivé. Planification et priorités restent dans GitHub ou Linear, ce qui convient à une équipe qui y gère déjà son backlog. La fin du cycle suit la pull request : commentaires GitHub renvoyés à l’agent, checks, fusion une fois la PR approuvée. Pour une équipe qui impose déjà PR et CI, le chemin est court.

Chez Singularity, l’unité visible est le ticket, et le board en est la file d’attente. Les statuts distinguent exécution active, attente explicite et échec relançable ; un parent peut attendre ses sous-tickets puis synthétiser leurs résultats ; le planificateur prend le prochain ticket prêt selon dépendances, priorité et limite d’agents. L’intégration est locale : approbation fichier par fichier, fusion partielle, rebase et file de commits. Vous poussez ensuite vers votre forge ; avec le plugin payant Pipelines, vous suivez GitHub Actions, GitLab CI ou Azure DevOps dans l’application. Dans les deux cas, relancez les tests après chaque intégration : un rebase propre ou une PR verte n’excluent pas un conflit sémantique.

Local, cloud et plateformes

Les deux outils exécutent les agents sur votre machine avec vos comptes ; prompts et extraits de code transitent par le fournisseur choisi, sauf modèle local via Ollama dans Singularity. Conductor ajoute, dès l’offre Pro, des workspaces cloud, la collaboration en direct, une API et une app iOS. Singularity n’offre ni exécution cloud hébergée ni application mobile : il reste une application de bureau, avec ses données dans une base SQLite locale. En revanche, Conductor n’est pas encore disponible pour Windows ni Linux, alors que Singularity publie des paquets pour ces deux systèmes : pour une équipe mixte, c’est souvent décisif.

Où Conductor est plus fort

• Cycle GitHub complet : workspaces créés depuis une PR ou une issue, PR rédigée avec l’agent, onglet Checks.
• Cloud et collaboration : workspaces cloud, collaboration en direct, API et app iOS dans les offres payantes.
• Gestion des ports : dix ports par workspace et un mode non concurrent.
• OpenCode : accès aux modèles configurés dans OpenCode.
• Rythme de livraison : plusieurs versions par semaine selon le journal des modifications.

Où Singularity se distingue

• Le ticket comme mission : dépendances, sous-tickets, planificateur et limite d’agents simultanés.
• Revue fine et locale : approbation par fichier, notes, fusion partielle, rebase et file de commits.
• Plus de fournisseurs : Copilot, Gemini, Mistral et Ollama en plus de Claude Code, Codex et Cursor.
• Environnement complet : éditeur, serveurs de langage, terminaux et cockpit Git.
• Plateformes et prix : macOS, Windows et Linux, application gratuite sans limite d’agents ni de worktrees.

Peut-on utiliser les deux ?

Oui, sur un Mac, si les deux outils ne gèrent jamais la même branche. Ils travaillent sur des dépôts Git ordinaires et pilotent les mêmes CLI Claude Code, Codex et Cursor. Gardez par exemple Conductor pour les tâches qui partent d’une issue GitHub et finissent en PR, et Singularity pour les chantiers découpés en tickets dépendants. Git interdit d’extraire une même branche dans deux worktrees : laissez chaque outil créer ses branches.

Quel outil choisir ?

• Équipe sur Mac, revue par PR GitHub et CI obligatoire : Conductor.
• Besoin de workspaces cloud ou de collaboration en direct : Conductor Pro ou Teams.
• Travail en tickets dépendants avec compte rendu par mission : Singularity.
• Postes Windows ou Linux : Singularity.
• Copilot, Gemini, Mistral ou modèles locaux via Ollama : Singularity.

Voyez aussi Singularity vs Superset, autre gestionnaire d’agents parallèles, ou Singularity vs Claude Code.

Protocole d’essai

1. Choisissez un dépôt avec des tests et une fonctionnalité en deux parties dépendantes.
2. Utilisez le même agent (par exemple Claude Code) dans les deux outils.
3. Dans Conductor, créez deux workspaces avec un script setup ; dans Singularity, deux tickets reliés par « Bloqué par », fusion automatique désactivée.
4. Notez vos interventions : questions, relances, gestion de l’ordre.
5. Relisez, intégrez (PR d’un côté, rebase de l’autre), puis lancez toute la suite de tests sur la branche de base.
6. Une semaine plus tard, vérifiez ce qui reste facile à retrouver : PR et workspaces archivés, ou tickets et comptes rendus.

Questions fréquentes

Conductor fonctionne-t-il sous Windows ou Linux ?

Pas au 10 octobre 2026 : sa page d’installation indique qu’il n’est pas encore disponible pour ces systèmes. Singularity publie des paquets macOS, Windows et Linux.

Faut-il payer les modèles en plus ?

Oui, dans les deux cas. L’offre gratuite de Conductor utilise vos abonnements et clés, et Singularity pilote les CLI de vos fournisseurs avec vos comptes.

Conductor exige-t-il GitHub ?

Sa page d’installation indique qu’il faut GitHub et au moins un fournisseur d’agent. Singularity n’impose pas de forge : il intègre localement et vous poussez où vous voulez.

Les worktrees suffisent-ils à éviter les conflits ?

Ils empêchent deux agents d’écrire dans les mêmes fichiers de travail. Des conflits Git ou sémantiques peuvent apparaître à la fusion de la PR chez Conductor, ou au rebase chez Singularity ; tests et relecture restent indispensables.

Pour aller plus loin, consultez tous les comparatifs Singularity, suivez le guide de démarrage ou téléchargez Singularity.