Avis sur Cursor Projects : l'agent coordinateur testé et expliqué (2026)

TL;DR

Cursor Projects, qui a été lancé le 10 septembre 2026, est la réponse de Cursor à un vrai problème : un chat IA classique oublie tout dès que vous le fermez. Un Project maintient un agent coordinateur actif pendant des semaines, et ce coordinateur n'écrit pas de code lui-même. Il planifie le travail, le délègue à une flotte de sous-agents cloud et vous ramène des pull requests à relire. Il peut aussi tourner seul, en surveillant un canal Slack ou vos PR ouvertes.

Comme je construis des agents IA qui font un vrai travail, ma lecture honnête : le modèle du coordinateur est la bonne idée, et le « contexte partagé qui grandit » est la partie qui compte vraiment. Le piège, c'est le modèle de coût. Vous payez le tarif API pour chaque sous-agent, et un coordinateur qui en lance beaucoup en parallèle relève de la gestion de facturation, pas d'une productivité gratuite. Idéal pour les migrations et la maintenance au long cours ; excessif pour une correction rapide.

Un cadrage à garder en tête avant de poursuivre : Cursor est une infrastructure pour construire des logiciels, pas un coéquipier qui fait un travail. Si vous voulez une IA qui prend en charge un rôle d'emblée (support, contenu), c'est une autre catégorie, et je dirai où les deux se rejoignent.

Ce qu'est vraiment Cursor Projects

Si vous avez déjà utilisé Cursor, vous connaissez le déroulé d'une session : vous ouvrez un chat, décrivez une tâche, l'agent modifie des fichiers, vous relisez, puis vous passez à autre chose. Fermez l'onglet et ce contexte disparaît. Pour une correction de 20 minutes, ça va. Pour une migration de trois semaines, vous finissez par réexpliquer votre code à un nouvel agent encore et encore.

Projects est conçu pour le second cas. Cursor le décrit comme un moyen de « s'attaquer à des chantiers plus vastes, comme une fonctionnalité, une migration ou une application complète », où le Project « conserve le contexte sur des mois de travail » et « effectue un travail récurrent sans qu'on le lui demande ». C'est le produit concret derrière la vision de la « troisième ère du développement logiciel » que Cursor avait lancée en février : piloter une flotte d'agents plutôt que de couver un seul chat.

Cursor affirme faire tourner Projects en interne depuis des mois, y compris pour des migrations de quelques centaines de PR, et avoir livré Projects lui-même avec un Project. Son chiffre phare : les nouveaux utilisateurs fusionnent 30 % de PR en plus, et les gros utilisateurs de Projects en fusionnent six fois plus. C'est un chiffre interne et auto-déclaré, à traiter comme n'importe quelle statistique de productivité d'un éditeur, mais il indique ce que le produit optimise : le débit de travail fusionné, pas les lignes tapées.

Le tout est en bêta et déployé auprès de tous les utilisateurs depuis le jour du lancement. Vous en démarrez un depuis la navigation de gauche, décrivez ce que vous voulez construire, et le coordinateur prend le relais.

L'agent coordinateur : le vrai changement

Voici la partie que je soulignerais. Quand vous ouvrez un Project, vous ne parlez pas à un agent de code. Vous parlez à un coordinateur, et selon le changelog de Cursor, « l'agent coordinateur d'un project n'écrit pas de code lui-même ; il planifie le travail, le délègue à des agents qui l'implémentent et vous rapporte le travail terminé pour vérification. »

Cela semble une petite distinction. Ce n'est pas le cas. Parce que le coordinateur délègue au lieu d'exécuter, Cursor affirme qu'« il n'est jamais bloqué et reste toujours réactif aux consignes. » Quiconque a regardé un agent unique ruminer une longue tâche connaît la frustration : on veut le réorienter, mais il est en pleine modification et injoignable. Un coordinateur contourne cela en n'étant jamais celui qui a les mains dans le code. Il crée et gère des agents en votre nom, en faisant tourner autant d'agents en parallèle que le travail l'exige, et Cursor présente le plafond comme le pilotage de « milliers d'agents via un seul coordinateur ».

En dessous, tout cela repose sur le système de sous-agents existant de Cursor, qu'il faut comprendre car il explique à la fois la puissance et le coût. Chaque sous-agent « opère dans sa propre fenêtre de contexte », part d'une page blanche, travaille de façon autonome et « renvoie son résultat à l'agent parent ». Ils peuvent tourner en parallèle, et depuis Cursor 2.5 un sous-agent peut même lancer ses propres sous-agents enfants, mais l'arbre s'arrête là : un sous-agent enfant ne peut pas en lancer d'autres. Si vous demandez l'isolation, chacun reçoit son propre Git worktree ou une VM cloud dédiée avec son propre clone du dépôt, afin que les agents parallèles ne s'écrasent pas. Les modifications restent sur des branches séparées jusqu'à la fusion par le parent.

Le compromis honnête, tiré de la documentation de Cursor : faire tourner cinq sous-agents en parallèle consomme environ cinq fois plus de tokens qu'un seul agent, et pour des tâches simples ils peuvent être plus lents, car chacun repart de zéro. Ce que vous achetez, c'est l'isolation du contexte, pas la vitesse. Il est honnête de la part de Cursor de le dire à voix haute, et c'est la phrase à laquelle je rattacherais une alerte de dépenses.

Cloud par défaut : où le travail s'exécute vraiment

Un Project tourne dans le cloud, pas sur votre ordinateur portable. La formule de Cursor : « cloud par défaut, local quand il le faut. » Un Project « tourne sur son propre ordinateur, donc fermer votre portable ne l'arrête pas », ce qui lui permet de « lancer plus de sous-agents en parallèle que votre portable ne le supporterait ». Quand quelque chose a vraiment besoin de votre machine, le coordinateur lance un agent local pour l'exécuter là.

Cela repose sur les Cloud Agents, l'infrastructure que Cursor appelait autrefois Background Agents : des VM isolées avec des environnements de développement complets qui clonent votre dépôt depuis GitHub, GitLab, Azure DevOps ou Bitbucket, travaillent sur une branche et renvoient des PR prêtes à fusionner avec des artefacts comme des captures d'écran et des journaux. Vous pouvez même contrôler le bureau distant d'un agent pour tester le logiciel modifié sans extraire la branche en local.

L'étape de configuration que l'on sous-estime, c'est l'environnement. Cursor est direct : « ne pas configurer d'environnement de développement pour vos agents cloud, c'est comme ne pas donner d'ordinateur à vos ingénieurs. » Vous le configurez avec un Dockerfile ou un snapshot enregistré, et si vous passez cette étape, vos agents travaillent à l'aveugle. Si vous avez déjà intégré une nouvelle recrue et l'avez vue perdre une journée à cause d'une installation locale cassée, vous savez pourquoi c'est important ; c'est la même taxe, payée une fois par Project.

Contexte partagé : la partie qui s'accumule

C'est la fonctionnalité que je trouve vraiment sous-estimée, et c'est celle qui fait de Projects davantage que des « agents en arrière-plan avec un plus joli nom ».

La phrase de Cursor : « vous ne devriez pas avoir à former un agent à chaque nouvelle tâche. » Chaque Project maintient donc un ensemble de fichiers synchronisés sur toutes les machines, cloud et locales, que ses agents utilisent. Les agents y consignent recherches, artefacts et « ce qu'ils apprennent sur le code et sur votre manière de préférer travailler ». L'exemple donné par Cursor : si un agent trouve comment tester un service, tous les futurs agents peuvent utiliser ces instructions.

C'est l'effet cumulatif. Le contexte « grandit avec le Project, ce qui rend le coordinateur plus efficace avec le temps ». C'est la différence entre engager un prestataire qui oublie votre code chaque matin et un autre qui est dans l'équipe depuis un mois. J'ai construit des systèmes où tout l'enjeu est de donner à un agent le bon contexte d'entreprise dès le départ, et je peux vous dire que la seconde version vaut bien plus qu'elle n'en a l'air sur une diapositive de lancement. C'est aussi la fonctionnalité la moins tape-à-l'œil de l'annonce, ce qui est souvent le signe que c'est la vraie.

Subscriptions : Cursor Projects en pilote automatique

L'autre gros titre, c'est qu'un Project peut agir sans vous. Cursor appelle cela Subscriptions, et le coordinateur peut « surveiller un canal Slack, s'exécuter selon un calendrier ou suivre toutes vos PR, en corrigeant la CI et en agissant à leur ouverture ou à leur fusion. » L'exemple concret du changelog : connectez Slack, pointez-le vers un canal de signalement de bugs, et le coordinateur se met à déléguer une correction chaque fois qu'un bug arrive.

Sous le capot, c'est le système d'Automations de Cursor, plus puissant que ne le laisse entendre le blog de Projects. Les déclencheurs peuvent se lancer sur un calendrier cron, sur des événements de gestion de code source (PR ouverte, poussée, fusionnée, CI terminée), sur des messages Slack ou des réactions emoji, sur un webhook auquel vous envoyez des requêtes POST, ou sur des événements Linear, Sentry et PagerDuty. Une automatisation peut ensuite ouvrir des PR, commenter, demander des relecteurs, publier dans Slack, utiliser des serveurs MCP et tenir des notes persistantes dans un fichier MEMORIES.md d'une exécution à l'autre.

Deux limites à connaître avant de vous y fier : seuls les canaux Slack publics sont visibles par les déclencheurs Slack pour l'instant, et les déclencheurs de PR ne s'exécutent pas sur les PR issues de forks (sauf le déclencheur de fusion). Aucune n'est rédhibitoire, mais ce sont le genre de choses que l'on veut découvrir avant, et non après, avoir bâti un flux de travail autour.

Les trois missions pour lesquelles Cursor Projects est conçu

Cursor est d'une précision rafraîchissante sur ce pour quoi cela convient, et cela correspond à ce pour quoi je l'utiliserais vraiment.

• Développement de fonctionnalités. Un Project commence par des agents qui étudient le système et consignent ce qu'ils apprennent, puis le coordinateur planifie et envoie des agents construire et tester des parties en parallèle. Après la mise en production, le même Project peut surveiller les journaux et traiter les signalements de bugs « avec tout le contexte des décisions d'origine ». Ce dernier point est la récompense du contexte partagé.
• Migrations. Cursor les qualifie de « faciles à commencer et difficiles à finir », ce qui est exactement juste. Vous établissez une approche sûre avec le coordinateur, et il l'applique progressivement à l'ensemble du code. Vous relisez chaque PR de près au début, puis vous relâchez à mesure que les corrections tiennent.
• Gardening (entretien). Un travail sans fin : qualité du code, surveillance des régressions. L'exemple réel de Cursor est un Project de design system où le coordinateur « analyse chaque nouvelle PR, extrait les composants qui appartiennent au design system et ajoute une règle de lint dès qu'il voit deux fois la même erreur », en passe de toucher 20 à 100 PR par jour.

Si votre travail ne ressemble à aucun de ces trois cas, un Project est probablement le mauvais outil. Voici le test rapide que je ferais avant d'en ouvrir un.

Ce que coûte Cursor Projects

C'est ici que je ralentirais. Projects n'a pas de prix affiché, et ce n'est pas Cursor qui cache son jeu : c'est vraiment facturé à l'usage. Projects s'exécute sur des Cloud Agents, et la facturation en découle.

Ce qu'il faut intégrer : un coordinateur qui lance de nombreux sous-agents en parallèle est un multiplicateur de coût, pas un repas gratuit. Sur un Project très actif, les « milliers d'agents » sont un plafond marketing, mais même une poignée d'agents cloud en parallèle aux tarifs des modèles de pointe fait vite grimper la note. C'est précisément l'inquiétude apparue dans les réactions de la communauté, et elle est légitime. Si vous faites déjà partie des équipes qui surveillent le coût par résolution d'un agent IA, vous voudrez la même rigueur ici : fixez des limites de dépenses et traitez les Subscriptions automatisées comme un compteur qui tourne.

Ce que disent les gens

Le tweet de lancement a cartonné, avec 5 861 mentions J'aime le premier jour. Mais la réaction la plus parlante à mes yeux est la réponse en tête, publiée onze minutes plus tard :

"can you pls just merge the subscriptions instead of just adding extra features?"

Gokul Bala, X

C'est la tension du jour du lancement en une ligne. Cursor empile les capacités, et certains de ses utilisateurs les plus engagés préféreraient qu'il simplifie l'existant plutôt que de livrer une nouvelle surface payante. Ce n'est pas tant une critique de la fonctionnalité qu'un signe que l'ensemble coordinateur, cloud et subscriptions représente beaucoup de nouveauté d'un coup.

La question stratégique la plus acérée est venue du responsable produit Aakash Gupta, qui écrivait sur la direction de Cursor vers des flottes d'agents dès avril 2026 :

"They're saying: the model is a commodity, the workflow is the moat. The question is whether developers want a dedicated cockpit for managing agent fleets, or whether the terminal where the model lives is enough."

Aakash Gupta, X

Je pense que c'est le vrai pari de Projects. Les modèles deviennent de plus en plus interchangeables, donc Cursor parie que la couche d'orchestration, le coordinateur, le contexte partagé et les déclencheurs, est l'endroit où il peut fidéliser. Préférer un cockpit ou une ligne de commande relève vraiment du goût, et des ingénieurs raisonnables se retrouvent des deux côtés. Si vous pesez ce choix, notre panorama des alternatives à Cursor et la comparaison Cursor vs Windsurf couvrent le spectre « cockpit contre terminal », tout comme toute comparaison avec OpenAI Codex ou la CLI de Claude Code.

Où Projects trouve sa place, et où il n'en a pas

Mon avis après avoir épluché la documentation : Cursor Projects est la version la plus cohérente de « gérer une flotte d'agents » que j'aie vue sortir, et la conception du contexte partagé en est la raison. Le modèle du coordinateur règle un vrai agacement, l'exécution cloud est sensée, et l'honnêteté de la documentation sur le coût des tokens et la lenteur des sous-agents inspire confiance.

Là où je freinerais : c'est en bêta, le modèle de coût récompense la retenue, et l'ensemble suppose que votre travail est vaste et durable. Pour un développeur solo qui fait des modifications rapides, c'est plus de mécanique que nécessaire, et un simple chat est le meilleur outil. Cela aiguise aussi une vraie inquiétude que l'une des réponses du fil de lancement a bien formulée : plus un coordinateur délègue, moins une ligne de code donnée a été écrite et relue par un humain. Projects mise beaucoup sur votre discipline pour relire les PR qu'il vous remet. C'est une fonctionnalité, pas un défaut, mais cela repose sur vous.

Et il y a un point de catégorie qui mérite d'être fait, car c'est ce à quoi je pensais sans cesse en lisant l'annonce.

Cursor est une infrastructure ; un coéquipier, c'est autre chose

Cursor Projects est une infrastructure de codage agentique. Il construit votre logiciel. Ce n'est pas un coéquipier qui arrive et fait un travail défini à votre place, et il ne cherche pas à l'être. C'est une vraie distinction, pas une critique.

C'est exactement ainsi que je pense ce que nous construisons chez eesel. eesel est une plateforme de coéquipiers IA, et vous embauchez des coéquipiers prêts à travailler pour des missions précises : un coéquipier IA pour le helpdesk qui rejoint votre file de support, et un rédacteur de blog IA. Chacun arrive avec les compétences, les intégrations et le contexte d'entreprise de son rôle, et travaille dès le jour zéro. Là où Cursor vous donne un cockpit pour construire des logiciels, eesel vous donne un collègue qui fait déjà le travail.

Le plus intéressant, c'est là où les deux se rejoignent. Car Cursor Projects adore une CLI et un déclencheur, et eesel aussi. La CLI eesel est une façon adaptée aux agents d'opérer le même coéquipier et le même espace de travail eesel que vous utiliseriez depuis le tableau de bord : une personne peut la lancer depuis un terminal, des scripts peuvent l'automatiser, et des agents de code comme Cursor, Claude Code et Codex peuvent la piloter. Ainsi, un Cursor Project qui répare votre application peut, dans la foulée, demander à la CLI eesel d'inspecter les instructions de votre coéquipier de support, de proposer une modification bornée et de relire les réponses de test avant qu'un humain l'approuve. Le même instinct de contexte partagé, appliqué au coéquipier qui répond à vos clients plutôt qu'au code qui les sert.

Si Projects vous fait penser à des agents qui font un vrai travail pendant que vous dormez, c'est le bon réflexe. Pour le volet support et contenu de ce travail, c'est le vide que comble eesel, et il est gratuit à essayer.

Essayez eesel pour le travail qu'un agent de code ne fera pas

Cursor Projects refera volontiers votre parcours de facturation. Il ne répondra pas aux 400 tickets « où est mon remboursement ? » que ces décisions provoquent. C'est la mission pour laquelle on embauche un coéquipier IA eesel pour le helpdesk : il se branche à Zendesk (et Freshdesk, Gorgias, Slack, etc.) en quelques minutes, apprend de vos anciens tickets et de votre centre d'aide, et commence à rédiger ou à résoudre dès le premier jour. C'est un agent IA embauché pour la file d'attente, facturé au ticket à prix fixe plutôt que par siège.

Et si vous vivez dans un terminal, vous n'avez pas besoin d'en sortir. La CLI eesel permet à votre agent de code d'inspecter et d'ajuster le même coéquipier eesel que le tableau de bord, de sorte que l'IA qui livre votre code puisse aussi aider à régler l'IA qui assiste vos clients. Vous pouvez essayer eesel gratuitement, sans carte bancaire, et le simuler sur vos vrais tickets historiques avant qu'il ne touche une seule conversation en direct.