Singularity vs Warp : deux ADE, terminal ou board d’agents ?

Warp s’est fait connaître comme un terminal moderne, puis s’est réinventé autour des agents IA. Son dépôt le présente comme « un environnement de développement agentique né du terminal », et son site met en avant des agents cloud et des « software factories » qui transforment une demande Slack ou Linear en pull request. Il attire ceux qui vivent dans la ligne de commande et les équipes qui automatisent dans le cloud.

Singularity revendique aussi l’étiquette ADE, avec un autre centre de gravité : une application de bureau organisée autour d’un board Kanban, où chaque ticket est confié à un agent qui travaille en local dans un worktree Git isolé, puis passe par une revue et une intégration par rebase. La décision porte donc moins sur « quel terminal ? » que sur « où organiser le travail des agents : dans un terminal et un cloud d’exécution, ou sur un board local qui suit chaque tâche jusqu’à votre branche ? ».

Comparatif vérifié le 10 octobre 2026 à partir de la documentation officielle de Warp 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 (Warp) et EUR (Singularity) tels qu’affichés, hors taxes et consommation ; ils peuvent évoluer.

En bref

• Warp part du terminal et y ajoute un agent, un éditeur, un panneau de revue, puis des agents cloud et des Warp Factories qui livrent des pull requests.
• Singularity part du board : tickets, dépendances, un worktree par exécution, revue et intégration par rebase dans une file ordonnée.
• Économie opposée : Warp vend de l’usage d’agent inclus dans ses offres ; Singularity est gratuit et ne revend aucun modèle.
• Local ou cloud : Warp peut exécuter des agents sur son infrastructure ; Singularity exécute tout sur votre poste.

Présentation de Warp

Sur son site, Warp se décrit comme une « open infrastructure for cloud software factories » et liste trois produits : Warp Factories, le terminal Warp et la CLI Warp Agent ; sa documentation parle d’« Agentic Development Environment ». Le client est open source depuis le 28 avril 2026, annonce Zach Lloyd, avec OpenAI comme sponsor fondateur du dépôt ; selon le README, le framework d’interface est sous MIT et le reste sous AGPL v3. Warp tourne sur macOS, Windows et Linux, en x86_64 comme en ARM, et la création de compte y est facultative.

Le Warp Agent enchaîne des tâches en plusieurs étapes en lançant de vraies commandes, y compris des REPL ou des shells de base de données, et demande une autorisation avant d’exécuter, de modifier un fichier ou d’appeler un serveur MCP, selon des profils d’autonomie. Il tourne dans l’application, dans n’importe quel terminal via la CLI warp ou dans le cloud. Plusieurs conversations peuvent tourner en parallèle, un agent parent peut coordonner des enfants, et l’Agent Management Panel affiche des statuts comme Working, Blocked, Failed ou Success (Managing cloud agents). Warp détecte et enrichit aussi seize agents CLI tiers, dont Claude Code, Codex, Copilot CLI, Cursor CLI, Gemini CLI et Mistral Vibe.

Ce que Warp appelle Warp Code réunit un éditeur intégré, une intégration LSP pour Rust, Go, Python, TypeScript/JavaScript et C/C++, et un panneau Code Review qui montre les changements non commités, annule un bloc et envoie des commentaires en ligne à l’agent en cours. Les worktrees Git ont chacun leur panneau de revue ; la documentation les crée avec git worktree add. Côté modèles, Warp propose ceux d’OpenAI, Anthropic, Google et xAI, des modèles open-weights et plusieurs modes Auto. La clé personnelle (BYOK) couvre Anthropic, OpenAI et Google : stockée sur le poste, elle transite par le backend de Warp, ne s’applique pas aux agents cloud, et les modes Auto consomment toujours des crédits Warp.

Hors du poste, la plateforme d’automatisation lance des agents cloud sur planning, événement (mention Slack, échec de CI), appel API ou à la main, sur l’infrastructure de Warp ou sur des runners auto-hébergés en Enterprise. Les Warp Factories, en accès anticipé, attachent une équipe d’agents à des dépôts : un agent « foreman » fait passer le travail venu de Slack, GitHub, Linear ou Jira par triage, spécification, implémentation et revue, et rend généralement une pull request. La documentation précise que la factory ne fusionne jamais.

Singularity en quelques mots

Singularity est un ADE de bureau édité par Meteor Factory : un éditeur CodeMirror 6, de vrais terminaux système, un client Git (graphe, diffs, stash, worktrees), 31 serveurs de langage activables et des espaces de travail multiprojets. Son cœur, Mission Control, est un board Kanban qui sert de surface d’exécution aux agents. Un ticket porte la demande, la priorité et la configuration de l’agent, affiche le statut et l’activité en direct, puis conserve le compte rendu, les blocages et une résolution courte. Les tickets peuvent dépendre les uns des autres et se découper en enfants.

L’orchestration lance chaque exécution dans un worktree Git dédié, puis réapplique ses commits sur la branche de base par rebase ; une file ordonne les intégrations d’un même projet. Le résultat est intégré automatiquement ou attend dans l’onglet Revue, selon vos réglages. Tests et relecture restent indispensables. Singularity pilote les CLI de sept fournisseurs (Claude Code, Codex, Copilot, Cursor, Gemini, Mistral, Ollama) avec vos comptes. L’application est gratuite ; la Singularity Licence (24 €/mois par poste, 14 jours d’essai) débloque seulement les plugins payants du Marketplace, comme Pipelines pour la CI/CD. Voir les tarifs.

Tableau comparatif

Une même fonctionnalité dans les deux outils

Prenons un export CSV des factures, avec un endpoint API et un bouton dans l’interface.

Dans Warp, vous décrivez la demande au Warp Agent, ou lancez Claude Code dans un onglet. Pour mener l’interface en parallèle, vous créez un worktree avec git worktree add et y lancez un second agent. Le panneau Code Review de chaque worktree montre les changements ; un commentaire sur une ligne part à l’agent. Vous commitez, poussez et ouvrez la pull request vous-même. Avec Warp Factories, vous pouvez aussi déposer la demande dans Slack ou Linear et recevoir une PR préparée dans le cloud.

Dans Singularity, vous créez deux tickets, le bouton bloqué par l’endpoint. Le ticket API démarre dans un worktree créé automatiquement ; le ticket interface attend que le premier soit intégré. Si l’agent pose une question, le ticket passe en attente et vous répondez dans son fil. L’onglet Revue affiche ensuite le diff : approbation par fichier, note sur une sélection, relance avec retours ou fusion par rebase, dans l’ordre de la file. Dans les deux cas, la suite de tests reste le juge final.

Local ou cloud : où tournent les agents

C’est la différence la plus structurante. Warp exécute ses agents dans l’application, via la CLI sur n’importe quelle machine, ou dans le cloud. Selon sa page confidentialité, la télémétrie doit rester active pour utiliser l’IA sur l’offre gratuite, et les offres Business et Enterprise bénéficient d’un accord de non-conservation des données.

Singularity exécute tout sur votre poste. Il ne téléverse pas votre code de lui-même : seuls les CLI configurés communiquent avec leurs fournisseurs. Tickets, réglages et historiques restent dans une base SQLite locale, et avec Ollama en local l’inférence reste sur la machine. En contrepartie, Singularity n’offre pas d’agents exécutés sur une infrastructure distante.

Modèles et coûts : crédits ou comptes personnels

D’après la page tarifs de Warp, Build (20 $/mois, 18 $ en annuel) inclut 20 $ d’usage d’agent par mois aux tarifs API, Max (200 $/mois) en inclut 200 $, Business (50 $ par utilisateur et par mois, jusqu’à 25 sièges) 20 $ par siège avec SSO SAML, et Enterprise est sur devis. Les Factories ont leur propre grille : sans abonnement, l’usage est facturé 20 % au-dessus des tarifs API, et inférence, calcul et agents sont facturés séparément.

Singularity ne revend pas de tokens : chaque ticket consomme l’abonnement ou les crédits de votre fournisseur, ou rien avec un modèle Ollama local. Vous choisissez un modèle par ticket et pouvez en exclure de la sélection automatique, mais le suivi des dépenses se fait chez chaque fournisseur, sans tableau de bord unique.

Où Warp est plus fort

• Le terminal : c’est son métier d’origine ; celui de Singularity est un vrai PTY intégré, sans les fonctions avancées d’un terminal dédié.
• Les agents cloud : déclencheurs Slack, GitHub, Linear ou Jira, plannings, runners auto-hébergés, Factories avec évaluations.
• Le choix d’agents et de modèles : seize agents CLI tiers, modes Auto et routeurs personnalisés.
• L’agent hors de l’application : la CLI warp fonctionne dans tout terminal, y compris en SSH.
• L’open source : le client Warp est ouvert ; Singularity est propriétaire.

Où Singularity se distingue

• Le ticket comme unité de travail : spécification, dépendances, enfants, statut et compte rendu au même endroit.
• Un worktree automatique par exécution, sans commande à taper.
• Une intégration jusqu’à votre branche : revue par fichier, fusion partielle, rebase et file, là où Warp s’arrête aux changements locaux ou à la PR.
• Un fonctionnement local, sans intermédiaire entre vos CLI et leurs fournisseurs.
• Un environnement de code plus large : 31 serveurs de langage, client Git avec graphe, espaces multiprojets.

Peut-on utiliser les deux ?

Oui. Warp peut rester votre terminal système pendant que Singularity orchestre les tickets : ses worktrees, créés dans .singularity-worktrees/, sont des dossiers Git ordinaires que vous ouvrez dans un onglet Warp pour lancer des tests ou relire un diff. Claude Code, Codex, Copilot, Cursor, Gemini et Mistral Vibe fonctionnent des deux côtés avec vos comptes. Évitez seulement deux agents dans le même worktree au même moment. Pour comparer avec un agent CLI seul, lisez Singularity vs Claude Code.

Quel outil choisir ?

• Vous vivez dans le terminal et voulez un agent à portée de prompt : Warp.
• Votre équipe veut des agents déclenchés par Slack, Linear ou la CI, dans le cloud : Warp.
• Vous déléguez plusieurs tâches par jour et voulez suivre chacune jusqu’à votre branche : Singularity.
• Votre code ne doit pas transiter par un intermédiaire : Singularity, éventuellement avec Ollama.

Protocole d’essai

1. Choisissez une fonctionnalité réelle touchant API et interface, avec des tests existants.
2. Utilisez le même agent des deux côtés, Claude Code ou Codex par exemple, pour comparer les workflows.
3. Dans Warp, menez les deux parties dans deux worktrees, commentez via Code Review, puis commitez et ouvrez la PR.
4. Dans Singularity, créez deux tickets liés par une dépendance, fusion automatique désactivée, et passez par l’onglet Revue.
5. Comparez temps de relecture, interventions, lisibilité de l’historique et coût facturé par chaque fournisseur, puis lancez toute la suite de tests.

Questions fréquentes

Warp est-il gratuit ?

Il existe une offre Free à 0 $, avec un accès limité aux agents cloud et un usage supplémentaire payé à la consommation. Build, Max et Business incluent un montant d’usage d’agent, selon la page tarifs de Warp au 10 octobre 2026.

Puis-je utiliser Claude Code dans les deux ?

Oui. Warp le reconnaît comme agent CLI tiers et comme harnais pour ses agents cloud ; Singularity le pilote comme fournisseur pour chaque ticket, avec votre compte Anthropic.

Singularity a-t-il des agents dans le cloud ?

Non, ses agents tournent sur votre poste. Pour des agents déclenchés à distance, voyez aussi Singularity vs Devin.

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