Le 10 septembre, Cursor a lancé la fonctionnalité Projects, actuellement en version bêta et ouverte à tous les utilisateurs. Elle vise les travaux qui s'étendent sur plusieurs PR et durent plusieurs semaines, voire plusieurs mois : développement de nouvelles fonctionnalités, migration de framework, ou construction d'une application complète à partir de zéro.
La structure comporte deux niveaux. Le niveau supérieur est un agent coordinateur qui n'écrit pas de code lui-même, mais se contente de répartir le travail entre les agents situés en dessous. Selon Cursor, le coordinateur ne fait que déléguer et n'exécute jamais rien lui-même ; il ne reste donc jamais bloqué sur une tâche particulière et peut recevoir à tout moment de nouvelles instructions humaines. Le niveau inférieur est composé de sous-agents qui écrivent le code ; selon l'annonce officielle, un projet peut en diriger des milliers.
"It doesn't write code itself but directs other agents that do."
(Il n'écrit pas de code lui-même, il ne fait que diriger les autres agents qui, eux, en écrivent.)
Trois capacités sous-jacentes
Projects repose sur trois piliers :
- Priorité au cloud : les projets s'exécutent sur des serveurs dédiés et ne s'interrompent pas même si l'ordinateur portable est fermé ;
- Contexte partagé : les fichiers sont synchronisés entre le cloud et la machine locale, de sorte que ce qu'un agent a déjà compris peut être directement réutilisé par les agents suivants ;
- Abonnements aux événements : un projet peut surveiller un canal Slack, s'exécuter selon un calendrier prédéfini, ou réagir automatiquement au statut d'une PR.
Cursor propose trois usages types. Pour développer une nouvelle fonctionnalité, plusieurs agents commencent par explorer en parallèle le système existant, puis implémentent séparément les différents composants ; pour une migration, les équipes s'en servent pour remplacer progressivement le framework et le système de style sur des centaines de PR ; pour la maintenance, le coordinateur surveille en continu la qualité du code et les régressions.
L'exemple du système de design
Le cas décrit le plus précisément dans le billet de blog est la maintenance d'un système de design : le coordinateur analyse chaque nouvelle PR, en extrait les composants qui devraient être intégrés au système de design, et ajoute une règle de lint dès qu'une même erreur se reproduit une seconde fois. Selon les estimations de Cursor, ce type de projet traite entre 20 et 100 PR par jour.
Un calcul rapide permet de mesurer ce que représenterait ce volume pour des humains. En supposant qu'examiner sérieusement une PR de taille moyenne prenne de 15 à 30 minutes, 20 PR par jour représentent 5 à 10 heures, ce qu'une seule personne peut tout juste assumer ; 100 PR par jour représentent 25 à 50 heures, ce qui, à raison de 8 heures de travail par personne et par jour, nécessiterait de trois à six relecteurs à temps plein. À mesure que la vitesse de production des machines augmente, le goulot d'étranglement se déplace vers la relecture, à moins que l'équipe n'accepte qu'une partie des PR soit fusionnée après avoir simplement passé les contrôles automatiques. Cursor ne précise pas quelle proportion des PR générées par Projects sont réellement relues par un humain avant d'être fusionnées.
D'où vient ce facteur six
Cursor avance deux chiffres de résultat : en interne, les nouveaux utilisateurs fusionnent 30 % de PR en plus ; et chez les utilisateurs qui travaillent principalement via Projects, le volume de fusions est six fois supérieur à avant. Ces deux chiffres proviennent des propres employés de Cursor, ne mesurent que le nombre de PR fusionnées, ne tiennent pas compte de la taille des PR, du travail de reprise ni des retours en arrière, et ne précisent pas non plus quelle est la base de comparaison pour ces 30 %. Aucune donnée en provenance d'équipes externes n'est disponible pour l'instant.
Côté tarification, le billet de blog ne dit pas si Projects sera facturé séparément, ni selon quel critère seront comptabilisés des milliers de sous-agents fonctionnant simultanément. Faire tourner en continu des centaines, voire des milliers d'agents dans le cloud ne devrait pas être bon marché, et ce point reste suspendu à des précisions futures de Cursor sur sa facturation.
Deux étapes reliées en une seule ligne
En remettant Projects dans le contexte des mouvements de Cursor ces six derniers mois, il s'agit du maillon suivant de cette chaîne. Lors du lancement de la version 3.0 en avril, Cursor avait repositionné son IDE comme une interface de gestion d'agents ; début septembre, l'entreprise a permis aux agents cloud de s'exécuter directement sur les serveurs propres des entreprises. Projects relie ces deux étapes : les humains gèrent le coordinateur, le coordinateur gère les agents exécutants, et ces derniers peuvent tourner aussi bien dans le cloud que sur les serveurs propres de l'entreprise.
Le même jour, l'Agents API lancée par OpenAI permet elle aussi à un agent principal de répartir des tâches entre des sous-agents, mais les deux entreprises n'attaquent pas le problème sous le même angle : OpenAI vend aux développeurs une base pour construire leurs propres agents, tandis que Cursor vend un produit fini qui effectue directement le travail à la place des équipes. L'accès à Projects se trouve dans la barre de navigation de gauche, et Cursor recommande officiellement de ne l'utiliser que pour des travaux s'étendant sur plusieurs PR ou se prolongeant sur une durée importante.
Sources : blog officiel de Cursor, CocoLoop, MarkTechPost ; les détails sur l'échelle des sous-agents, le taux d'augmentation des fusions de PR et les exemples de cas ont été vérifiés à partir du blog de Cursor.