Du ticket à la pull request relue : Cursor, Augment Code, Warp et Factory comparés

Du ticket à la PR relue, tel que chaque éditeur le documente sur ses pages produit, tarifs et sécurité

Le besoin commun : un ticket en entrée, une pull request relue en sortie

Les quatre éditeurs décrivent des agents qui prennent une tâche d'ingénierie et rendent un résultat qu'une personne peut relire. Ils n'y arrivent pas par le même chemin. Cursor est un éditeur de code avec un CLI, une intégration Slack et des agents cloud. Augment Code vend Cosmos, une plateforme d'orchestration bâtie sur un moteur de contexte. Warp associe un terminal, un Agent CLI et Warp Factories, des flottes d'agents définies en code. Factory construit des agents appelés Droids et y ajoute revue de code, analytique et automatisations.

Cette comparaison suit une seule tâche : un ticket dans un dépôt existant, implémenté par un agent, qui aboutit à une pull request qu'un humain peut lire et approuver. Ce n'est pas un classement et il n'y a aucun benchmark. Tout repose sur des pages produit, tarifs et sécurité des éditeurs relues le 15 octobre 2026 : on décrit donc ce que disent les éditeurs. Quand une page se tait, le point est inconnu, pas absent. Warp Factories est présenté en accès anticipé, ce qui compte pour un déploiement.

Sources : cursor.com · augmentcode.com · warp.dev · factory.com

Contexte du dépôt : ce que chaque page documente

La page d'accueil de Cursor montre son agent lisant des fichiers et lançant des recherches avant de modifier le code, et cite l'indexation sécurisée de la base de code et la recherche sémantique parmi ses sujets de recherche publiés. Le fonctionnement de l'indexation n'est pas expliqué sur cette page. Cursor liste aussi des connexions de marketplace comme Slack, Notion, Docker ou Google Drive, qui peuvent apporter du contexte hors code.

Augment Code place un Context Engine au cœur de Cosmos et décrit une connaissance d'organisation partagée, c'est-à-dire une mémoire commune aux agents et aux équipes. Ses déclencheurs couvrent GitHub, GitLab, Slack, Linear et Jira. Dans une étude de cas publiée par Augment, l'équipe Handoff indique que l'outil respectait son architecture et ses conventions de nommage, et que la liaison de Linear et Figma via MCP lui donnait plus de détails d'implémentation.

Warp définit une factory dans un fichier de configuration qui relie dépôts, secrets, serveurs MCP, comptes cloud et intégrations Slack, Linear ou Jira ; chaque exécution récupère le code concerné. La page ne décrit pas d'indexation sémantique : c'est une question ouverte. Factory met en avant AutoWiki, un wiki vivant par dépôt, et Agent Readiness, un score par dépôt, sans détailler comment le code est indexé.

Sources : cursor.com · Marketplace (cursor.com) · augmentcode.com · Handoff scaling with augment code (augmentcode.com) · warp.dev · factory.com

Où l'agent s'exécute

Cursor existe en application desktop, en CLI et en application Slack. Ses agents cloud sont décrits comme utilisant leurs propres ordinateurs pour construire, tester et démontrer le travail en parallèle. Le marketplace propose des automatisations comme corriger les bugs signalés dans un canal Slack par une pull request, ou trier les tickets Linear en ouvrant des pull requests pour les correctifs simples. L'auto-hébergement n'est pas mentionné dans les pages lues.

Augment indique que Cosmos fonctionne sur laptops, VM de développement, son propre cloud géré ou le cloud du client sur AWS ou GCP, avec des bacs à sable isolés. Sa page tarifs mentionne calcul standard, mode daemon et 50 sessions simultanées en Standard et Business, et calcul personnalisé multi-région en Enterprise. Standard coûte 20 $ par mois et Business 100 $, forfait fixe jusqu'à 50 places, avec un usage mutualisé. L'usage des modèles est facturé au tarif public du fournisseur plus 40 % de frais de service, selon l'éditeur.

Warp affirme que les factories peuvent tourner dans son cloud ou en auto-hébergement dans votre VPC, avec n'importe quel modèle ou harnais, et que personne n'a besoin du terminal Warp pour les utiliser : le travail arrive de Slack, Linear, Jira, GitHub ou GitLab. La tarification est décrite comme à l'usage, par exécution d'agent. Factory s'installe par CLI et cite les Droid Computers, du matériel dédié qui exécute les agents en local avec état persistant, et Mission Control pour suivre les exécutions. Sa page sécurité décrit un environnement mono-locataire avec son propre VPC ; l'exécution cloud des tickets n'est pas détaillée sur la page d'accueil.

Sources : cursor.com · augmentcode.com · Pricing (augmentcode.com) · warp.dev · factory.com

Comment le changement est vérifié avant l'approbation humaine

Cursor dit relire les pull requests dans GitHub, et sa démo montre des tâches prêtes pour revue. Son marketplace liste des automatisations pour corriger la CI, traiter les commentaires de revue et chercher des vulnérabilités, ainsi qu'une automatisation qui assigne des relecteurs et approuve automatiquement les pull requests à faible risque. L'approbation humaine obligatoire par défaut n'est pas précisée : le schéma d'approbation dépend donc de la configuration de ces automatisations.

Augment décrit une flotte de revue de code, un Tester qui exerce le changement de bout en bout et publie les résultats avec captures d'écran, et des quality gates où le travail se met en pause pour revue et où les actions importantes exigent l'approbation d'une personne. C'est le langage de point de contrôle humain le plus explicite des quatre. Sa FAQ tarifs distingue la revue de code standard pour les pull requests GitHub d'une version Enterprise avec analytique, listes d'utilisateurs autorisés et multi-organisations.

Le fichier de factory de Warp fixe déclencheurs, agents, modèles et portes d'approbation ; Warp dit que chaque exécution est évaluée et que les agents capturent une image ou une vidéo comme preuve avant la pull request. Les chiffres de sa page sont des illustrations, pas des mesures. Factory propose une revue de code sur chaque pull request avec commentaires en ligne, des automatisations où les droids planifient, exécutent et valident, et Droid Shield, censé détecter vulnérabilités, bugs et problèmes de propriété intellectuelle dans le code généré. Ses points d'approbation ne sont pas détaillés.

Sources : cursor.com · augmentcode.com · warp.dev · factory.com

Ce que montrent les workflows clients

Rectangle Health, entreprise de paiement santé avec 30 ingénieurs, offre l'histoire publiée la plus proche d'un parcours ticket-vers-pull-request, dans l'étude de cas de Warp elle-même. Il s'agit d'un déploiement d'Oz : un ingénieur senior a branché des agents sur Oz, la plateforme d'orchestration cloud de Warp, au workflow Jira pour qu'un ticket mène à une pull request, puis a ajouté un bot Slack. Le résultat, Rex, trie les demandes et les route vers des agents de recherche, développement, revue et QA. Warp annonce environ 100 exécutions d'agents cloud par semaine, typiquement 3 à 10 minutes entre la mention Slack et la pull request, et 139 commits sur 11 dépôts en 60 jours de développement actifs.

L'étude cite Oz, Warp Terminal et des déclencheurs Slack et Jira comme produits utilisés. Elle ne mentionne pas Warp Factories : elle ne valide donc pas Factories. Elle montre en revanche une boucle de tickets construite par le client. L'équipe indique que de petits éléments du backlog, comme des requêtes SQL lentes, restaient en souffrance depuis des mois, et lorsque le CTO a testé les agents sur de telles requêtes, ils ont rendu deux pull requests sur deux dépôts.

Les études de cas d'Augment montrent un autre type de travail. Handoff, équipe de 13 personnes sous VS Code, a délégué des éléments comme des écrans depuis Figma et affiné d'autres parties en parallèle. La page d'Augment indique que le temps de cycle des pull requests de cette équipe est passé de 2,14 à 1,07 heure entre août et novembre 2025. Peek, environ 25 ingénieurs, a testé trois semaines chacun GitHub Copilot, Cursor et Augment, et rapporte que l'automatisation de tests est passée de deux ou trois jours à quelques heures. La page ne donne aucun résultat pour Cursor : ce n'est pas un duel. Les deux histoires portent surtout sur un assistant dans le flux du développeur, pas sur une boucle ticket de Cosmos.

La page clients de Cursor contient des témoignages d'entreprises comme Optiver, qui évoque un déploiement à l'échelle de la société, et Mercado Libre, qui cite des fonctionnalités construites en une journée dans certains cas. Ce sont des témoignages d'adoption, pas des parcours ticket-vers-pull-request. L'histoire de Docker avec Warp concerne le terminal, pas des agents sur tickets : une bibliothèque partagée de plus de 40 commandes dans Warp Drive, avec des questions à Warp AI, a ramené l'intégration d'environ quatre semaines à trois. Pour Factory, cet article s'appuie sur des pages produit et de confiance : son workflow est décrit dans les termes de l'éditeur.

Sources : Rectangle health uses warp to build a self improving ai teammate (warp.dev) · warp.dev · Handoff scaling with augment code (augmentcode.com) · Peek (augmentcode.com) · augmentcode.com · Customers (cursor.com) · Docker (warp.dev) · factory.com

Sécurité, permissions et conditions sur les données

Cursor cite SOC 2 Type II, ISO 27001 et ISO 42001, et sa page sécurité mentionne aussi AIUC-1. Il indique que, Privacy Mode activé, il n'entraîne pas de modèle sur vos données, et que les administrateurs d'équipe peuvent l'imposer. Sa documentation couvre SSO et SCIM, CMEK, journaux de conformité et sécurité réseau des agents cloud. Augment cite SOC 2 Type II et ISO 42001 et affirme ne pas entraîner de modèle sur les données clients par défaut. Sa page tarifs résume l'offre Enterprise ainsi : prise en charge de SSO, OIDC et SCIM, plus CMEK et conformité ISO 42001. Dans sa comparaison de sécurité, la même page nomme aussi l'intégration SIEM, les options de résidence des données, les contrôles d'accès granulaires et les pistes d'audit, mais le texte n'indique pas quelle offre inclut chacun de ces éléments.

Warp déclare détenir une attestation SOC 2 Type 2, stocker les données aux États-Unis sur Google Cloud, chiffrer en AES-256 et TLS 1.3, proposer une rétention zéro pour l'IA en Enterprise et publier un accord de traitement des données. Cette page décrit le terminal et ses fonctions d'IA : vérifiez ce qui s'applique à Factories, que Warp dit pouvoir auto-héberger. Le trust center de Factory liste des documents SOC 2, ISO 27001 et ISO 42001 et des sous-traitants publiés ; Factory dit ne pas entraîner de modèle sur les données clients par défaut et publie un DPA qui indique un traitement principal aux États-Unis. Ses avis récents ajoutent Meta, Databricks, Snowflake et Mistral comme sous-traitants pour le traitement par des modèles d'IA.

Sources : Security (cursor.com) · cursor.com · Security (augmentcode.com) · Pricing (augmentcode.com) · augmentcode.com · Security (warp.dev) · Data processing addendum (warp.dev) · trust.factory.com · Security (factory.com) · Data processing agreement (factory.com)

Qui présélectionner, et que demander en démonstration

Ce sont des suggestions éditoriales, pas des affirmations d'éditeurs. Retenez Cursor si vos développeurs vivent déjà dans un éditeur et que vous voulez un seul produit pour le travail interactif et les agents cloud déclenchés depuis Slack et GitHub. Retenez Augment Code si vous voulez des boucles orchestrées avec points de contrôle humains explicites, mémoire partagée et possibilité d'exécuter dans votre cloud. Retenez Warp Factories si vous voulez toute la configuration en code, le libre choix du modèle et du harnais, et l'auto-hébergement, et que vous acceptez l'accès anticipé ; demandez à Warp des preuves propres à Factories, car l'étude client lue ici porte sur Oz. Retenez Factory si l'hébergement mono-locataire, les journaux d'audit exportables vers un SIEM et l'analytique d'usage comptent le plus.

Quatre questions les départagent en démonstration. Où le code s'exécute-t-il, et peut-il rester dans notre réseau ? Qui doit approuver avant l'ouverture ou la fusion d'une pull request, et est-ce imposé ou facultatif ? Quelles preuves accompagnent la pull request, comme des résultats de tests ou des captures ? Et quels documents de sécurité couvrent exactement la surface produit que nous utiliserions ? Le nombre de clients publics n'est pas un signal de préférence, et les chiffres clients ci-dessus, rapportés par les éditeurs sur des équipes différentes, ne se comparent pas entre eux.

Sources : cursor.com · augmentcode.com · warp.dev · factory.com