Cursor veut faire tourner vos agents et héberger le code qu'ils écrivent

Les notes de version de Cursor ressemblent d'ordinaire à des listes de fonctionnalités. Celle-ci ressemble à une revendication de territoire. Dans une annonce publiée aujourd'hui, l'entreprise a lancé Projects, une couche où un agent coordonnateur planifie le travail et le confie à des sous-agents, aux côtés d'Origin, son propre hébergeur de code avec dépôts, pull requests et synchronisation bidirectionnelle avec GitHub.

Les deux arrivent en bêta plutôt qu'en produits finis, et les questions qu'ils laissent ouvertes comptent davantage que la liste des fonctionnalités.

Ce que Cursor a réellement livré aujourd'hui

Projects prend en charge les gros chantiers : une fonctionnalité, une migration, une application entière. Son agent coordonnateur n'écrit pas le code lui-même. Il planifie le travail, le délègue à des agents qui l'implémentent, puis renvoie le résultat fini pour revue, en exécutant autant d'agents en parallèle que la tâche l'exige. Un projet tourne sur sa propre machine dans le cloud, si bien que fermer un ordinateur portable ne l'arrête pas, et lorsqu'un test doit s'exécuter localement, le coordonnateur lance un agent local pour l'y exécuter.

Origin couvre l'hébergement, en commençant par les dépôts, les pull requests, la navigation dans le code et la synchronisation GitHub, des fonctionnalités natives pour agents étant promises plus tard. Les agents cloud n'ont plus besoin d'une connexion à GitHub ou à un SCM tiers pour démarrer, et les workers auto-hébergés prennent désormais en charge le « computer use » sous Linux et Mac.

Projects est en bêta et se déploie progressivement auprès de tous les utilisateurs à partir d'aujourd'hui. Origin atteint la bêta précoce sur les offres payantes aujourd'hui, à l'exclusion des organisations Enterprise dont les administrateurs refusent d'y participer.

Origin contre GitHub : la question de la source de vérité

Cursor ne présente pas Origin comme un remplacement de GitHub, et la mécanique le confirme. Pour les dépôts hébergés sur Origin, Origin est la source de vérité et les push n'atteignent jamais GitHub. Pour les dépôts importés depuis GitHub, GitHub reste la source de vérité, les push continuent d'y aller, et Origin reflète le résultat. Les pull requests sur les dépôts synchronisés circulent dans les deux sens : un commentaire laissé dans Cursor est publié sur GitHub, et une réponse sur GitHub arrive dans Cursor en quelques secondes.

Le poids se trouve dans l'autre cas de figure : un dépôt créé dans Origin, travaillé par des agents, revu et fusionné à l'intérieur de Cursor, sans jamais toucher GitHub. Les dépôts portent un nom de codebase qui devient une partie de leur URL, cursor.com/codebase/acme-corp, et Cursor câble en parallèle un écosystème d'applications, avec des intégrations Vercel, Depot et Buildkite disponibles dès maintenant et Vercel offrant à chaque pull request un déploiement de prévisualisation.

L'affirmation du coordonnateur et des sous-agents, confrontée au texte

L'affirmation à isoler est que le coordonnateur n'écrit pas le code. Il planifie, délègue et renvoie le travail pour vérification, en exécutant autant d'agents en parallèle que le travail l'exige. Cursor affirme que Projects délègue des tâches à des milliers de sous-agents. Les sous-agents peuvent désormais tourner sur leurs propres machines virtuelles, chacune avec une copie isolée du projet et un contexte propre dans son propre environnement cloud, ce qui élimine le risque que des correctifs parallèles entrent en collision dans les mêmes fichiers.

C'est une réponse sensée à un problème réel. Ce que l'annonce n'offre pas, c'est une mesure. Aucun taux de réussite, aucun plafond sur le nombre d'agents qu'un coordonnateur gère avant que la qualité ne chute, aucun exemple publié d'un projet tournant pendant les mois de contexte que Cursor décrit. Un Project maintient un ensemble de fichiers partagés synchronisé entre ses machines cloud et locales, et les agents y ajoutent des recherches, des artefacts et ce qu'ils apprennent sur le codebase. Le mécanisme est plausible, et non testé.

Capacité auto-hébergée : la plomberie enterprise derrière la bêta

L'offre enterprise de Cursor repose sur trois options distinctes.

Les pools ne sont pas liés à un seul dépôt : nommez un pool et tout worker disponible peut prendre la requête en charge. Les agents cloud peuvent aussi tourner sur une infrastructure que l'acheteur exploite déjà, notamment AWS Lambda, Coder, Cloudflare, Daytona, Modal, Namespace, Vercel et E2B. Cette liste vise des équipes qui ne confieront pas leurs artefacts de build ou leurs secrets au cloud d'un fournisseur, et dont la revue de sécurité bloque précisément sur ce point.

Ce qu'il faut surveiller : tarification, fiabilité et clause de retrait

Trois lacunes ressortent. Cursor n'a publié aucun prix pour Projects, Origin, les pools auto-hébergés ou les partenaires d'infrastructure qu'il a cités. Le déploiement d'Origin exclut les organisations Enterprise dont les administrateurs choisissent de ne pas participer, ce qui suggère que l'entreprise s'attend à des résistances de la part d'acheteurs qu'elle a passé une section à courtiser. Et les affirmations d'autonomie, des agents qui suivent un canal Slack ou une pull request et agissent sur ce qu'ils y trouvent, dépendent de boucles que seul un déploiement soutenu peut tester. Savoir si ces boucles tiennent en troisième semaine n'est pas une question à laquelle un billet de lancement répond.