Cursor a lancé Projects le 10 septembre 2026. Au lieu d'ouvrir un nouveau chat pour chaque tâche, vous travaillez dans un fil persistant avec un agent coordinateur qui planifie un gros volume de travail et confie le codage proprement dit à une flotte de sous-agents exécutés en parallèle, surtout dans le cloud.
Ce qui est intéressant, ce n'est pas « plus d'agents ». C'est le changement de ce qu'est votre travail. Vous cessez de surveiller un seul agent et vous dirigez le travail à un niveau plus élevé, en relisant des résultats terminés plutôt qu'en regardant le code se taper. Cursor appelle cela la « troisième ère du développement logiciel » et affirme en interne que les utilisateurs qui travaillent surtout dans Projects fusionnent six fois plus de PR.
C'est réellement utile pour le travail qui dépasse un seul chat : grosses fonctionnalités, longues migrations et maintenance sans fin. C'est aussi une vraie question de coût et de contrôle, car un coordinateur qui lance de nombreux sous-agents cloud facture au tarif API et place plus de lignes de code entre vous et le dernier humain qui les a lues. Je construis des systèmes d'agents chez eesel, donc je détaille ci-dessous exactement comment fonctionne Projects, ce qu'il coûte, où les sceptiques ont raison et à quoi ressemble ce modèle « vous dirigez, les agents travaillent » en dehors du code.
Ce qu'est vraiment Cursor Projects
Un Project est un conteneur pour un gros chantier. Le cadrage de Cursor : il vous permet de « prendre en charge de plus gros volumes de travail, comme une fonctionnalité, une migration ou une application complète ». Là où un chat oublie tout dès que vous le fermez, un Project conserve le contexte pendant des mois, peut déléguer à de nombreux agents et peut même agir sur du travail récurrent sans sollicitation.
Vous en démarrez un depuis la navigation de gauche, vous décrivez ce que vous voulez construire, et le coordinateur prend le relais. C'est en bêta et déployé auprès de tous les utilisateurs à compter de la date de lancement.
Si vous utilisiez Cursor comme un outil d'autocomplétion plus chat, c'est un saut plus grand que ne le laisse entendre le changelog. L'unité de travail passe de « un message » à « un projet », et ce que vous gérez passe de « le code » à « les agents ».
Le vrai changement : d'un agent à un coordinateur
Cursor construit cela depuis un moment. Dès février 2026, il décrivait une « troisième ère » où « des flottes d'agents prennent en charge des corps de travail entiers » et où le développeur dirige le travail plutôt que chaque agent. Projects est cette vision livrée.
Voici la trajectoire, car c'est la façon la plus claire de voir ce qui a changé :
À l'ère un, vous écriviez le code et l'IA suggérait la ligne suivante. À l'ère deux (où se trouvent encore la plupart des outils de codage agentique), vous donnez un prompt à un agent par tâche et vous le regardez travailler. Projects est un pari sur l'ère trois : vous dirigez un coordinateur, et le coordinateur fait tourner la flotte. Le coordinateur n'écrit pas de code lui-même ; comme il délègue plutôt qu'il n'exécute, « il n'est jamais bloqué et répond toujours aux directives ».
Ce dernier détail compte plus qu'il n'y paraît. Un agent seul est frustrant parce qu'il se concentre sur sa tâche et que vous attendez. Un coordinateur reste disponible pour discuter avec vous pendant que ses sous-agents travaillent, et c'est ce qui rend « diriger, ne pas surveiller » réellement différent en pratique.
Comment fonctionne un Project sous le capot
Derrière le marketing, Projects est une fine couche d'orchestration au-dessus de quatre éléments que Cursor avait déjà : le coordinateur, les sous-agents, l'exécution cloud et les déclencheurs d'automatisation. Voici comment ils s'articulent.
Le coordinateur planifie et délègue
Vous supervisez un Project en discutant avec son agent coordinateur. Il « planifie le travail, le délègue à des agents qui l'implémentent et vous rapporte le travail terminé à vérifier », en créant et gérant des agents pour vous et en en exécutant autant en parallèle que le travail l'exige. En dessous, chaque sous-agent travaille dans sa propre fenêtre de contexte, s'exécute de façon autonome et renvoie son résultat à l'agent parent. Depuis Cursor 2.5, les sous-agents peuvent même lancer leurs propres sous-agents enfants, bien que l'arbre s'arrête à un niveau de profondeur.
Une réserve honnête que la documentation formule clairement : le parallélisme n'est pas de la vitesse gratuite. Exécuter cinq sous-agents en parallèle consomme environ cinq fois les tokens d'un seul agent, et ils peuvent même être plus lents sur les tâches simples car chacun part d'un contexte vierge. Le gain, c'est l'isolation et l'échelle, pas la vitesse brute.
Cloud par défaut, local si nécessaire
Projects s'exécute sur les Cloud Agents (les VM cloud isolées auparavant appelées Background Agents). Un Project « tourne sur son propre ordinateur, donc fermer votre portable ne l'arrête pas », ce qui lui permet d'exécuter bien plus de sous-agents en parallèle que votre machine ne le pourrait. Quand quelque chose doit tourner sur votre poste, le coordinateur lance un agent local pour cela.
Ce qui compte vraiment ici, c'est l'environnement. Comme le dit Cursor, « 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 définissez via une configuration guidée par l'agent, un snapshot enregistré ou un Dockerfile, et les agents cloud clonent depuis GitHub, GitLab, Azure DevOps ou Bitbucket et poussent sur une branche pour la remise. Si vous avez déjà branché l'intégration GitHub de Claude Code ou équivalent, le schéma vous sera familier.
Un contexte partagé qui s'accumule
C'est la pièce que je trouve la plus sous-estimée. La phrase de Cursor : « vous ne devriez pas avoir à former un agent chaque fois que vous démarrez une tâche ». Chaque Project conserve un ensemble de fichiers synchronisés sur toutes les machines cloud et locales que ses agents utilisent, et les agents y écrivent recherches, artefacts et ce qu'ils apprennent sur votre base de code. L'exemple : « si un agent trouve comment tester un service, tous les futurs agents peuvent utiliser ces instructions ».
Résultat : le contexte grandit avec le Project et le coordinateur devient plus efficace avec le temps. C'est le même principe que de donner à un agent de support IA une vraie base de connaissances plutôt que de réexpliquer votre produit à chaque session, simplement appliqué à une base de code.
Les abonnements fonctionnent sans prompt
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 quand elles s'ouvrent ou fusionnent. Cursor commercialise cela sous le nom d'« abonnements » ; dans la documentation, c'est le système Automations, qui déclenche des agents cloud selon des calendriers ou des événements de GitHub, GitLab, Slack, webhooks, Linear, Sentry et PagerDuty. Pointez-le sur un canal de signalement de bugs et il commence à déléguer à chaque nouveau bug. C'est la couche d'automatisation qui transforme Projects d'un outil que vous ouvrez en quelque chose qui tourne, la même idée pilotée par des déclencheurs que derrière un chatbot IA pour Slack ou un chatbot IA de helpdesk qui agit sur les nouveaux messages.
Les trois types de travail pour lesquels Projects est conçu
Cursor est étonnamment précis sur ce à quoi cela convient, et cela se résume à trois schémas. C'est la partie à bien intégrer, car Projects n'est vraiment pas fait pour un correctif de cinq minutes.
- Développement de fonctionnalités. Les agents étudient le système et consignent ce qu'ils apprennent comme contexte partagé, le coordinateur planifie, et les sous-agents construisent et testent des parties en parallèle. Après la livraison, le même Project peut surveiller les logs et traiter les signalements de bugs avec tout le contexte derrière les décisions d'origine.
- Migrations. L'expression de Cursor : un travail « facile à commencer et difficile à finir ». Vous convenez d'une approche sûre avec le coordinateur, puis il l'applique progressivement à toute la base de code. Vous relisez chaque PR de près au début, puis vous relâchez à mesure que le schéma tient.
- Jardinage. Un travail qui ne se termine jamais vraiment, comme la qualité du code et les régressions. L'exemple de Cursor lui-même est un Project de design system dont le coordinateur analyse chaque nouvelle PR, extrait des composants et ajoute une règle de lint chaque fois qu'il voit deux fois la même erreur, en passe de toucher 20 à 100 PR par jour.
Le fil conducteur : cela rapporte quand le travail « dépassera un seul chat ». Pour un correctif rapide, un agent simple est plus rapide et moins cher.
Vous ne savez pas dans quelle catégorie tombe votre travail ? Voici un moyen rapide de vérifier avant de lancer un Project.
Très bon choix. Laissez d'abord les agents faire des recherches, le coordinateur planifier, puis construire et tester des parties en parallèle, et gardez le Project actif pour traiter les bugs plus tard.
Le cas classique de Projects : facile à commencer, difficile à finir. Fixez une approche sûre avec le coordinateur, relisez de près les premières PR, puis relâchez à mesure que le schéma fait ses preuves.
Configurez un abonnement pour que le coordinateur surveille chaque nouvelle PR, extraie des schémas et ajoute des règles de lint. C'est le cas idéal du « tourne sans vous ».
Utilisez plutôt un agent Cursor simple. Un correctif ponctuel n'a pas besoin d'un coordinateur, d'un contexte partagé ni de VM cloud, et un Project coûterait plus de tokens sans rien apporter.
Ce que coûte Cursor Projects
Projects n'a pas de prix catalogue, et c'est le titre honnête. Projects s'exécute sur des Cloud Agents, et les Cloud Agents sont facturés au tarif API du modèle que vous sélectionnez. Un forfait Cursor payant est requis pour exécuter des agents cloud, et un administrateur doit d'abord connecter le contrôle de source. Voici le tableau des coûts en termes simples.
| Quoi | Comment ça marche | Le piège |
|---|---|---|
| Forfait requis | Un forfait Cursor payant est nécessaire pour exécuter des agents cloud | Le forfait gratuit ne peut pas exécuter Projects dans le cloud |
| Unité de facturation | Les agents cloud sont facturés au tarif API du modèle choisi | Le coût suit les tokens consommés, pas un tarif mensuel fixe |
| Parallélisme | Le coordinateur exécute autant de sous-agents que le travail l'exige | Cinq sous-agents en parallèle ≈ cinq fois les tokens |
| Contrôle des dépenses | Vous définissez une limite de dépenses à la première utilisation | La limite est le garde-fou ; il n'y a pas de plafond fixe par défaut |
| Automatisations | Les abonnements sont facturés à l'usage des agents cloud et utilisent la fenêtre de contexte maximale de chaque modèle | Pas de réglage du contexte, donc les exécutions en arrière-plan peuvent consommer beaucoup de tokens |
Un exemple chiffré rend cela concret. Le Project de « jardinage » du design system décrit par Cursor est en passe de toucher 20 à 100 PR par jour. Chacune de ces exécutions est un agent cloud (souvent plusieurs sous-agents) facturé aux tarifs API du modèle, toute la journée, que vous regardiez ou non. Cela peut être une excellente affaire face au temps d'un ingénieur, ou une facture surprise, selon entièrement votre limite de dépenses et la verbosité des modèles. C'est pourquoi le tableau complet des tarifs de Cursor compte plus que jamais avec Projects, et pourquoi les craintes sur le coût à l'usage reviennent sans cesse dans les réactions de la communauté, ce qui nous amène à la partie intéressante.
Un « cockpit pour flottes d'agents » est-il ce que veulent vraiment les développeurs ?
Je veux être juste ici, car la réaction le jour du lancement n'a pas été que des applaudissements. Le post de lancement a recueilli 5 861 mentions J'aime, mais la réponse la plus bruyante au début était la lassitude, pas l'émerveillement :
"can you pls just merge the subscriptions instead of just adding extra features?"
C'est le commentaire principal sous l'annonce elle-même. Il traduit une inquiétude réelle : Projects empile une surface payante de plus, facturée au cloud, sur un produit déjà chargé. Et en avril 2026, le rédacteur produit Aakash Gupta a bien résumé le pari stratégique (en parlant de l'orientation de Cursor, pas de ce lancement précis) :
"Cursor's move is to go vertical on the orchestration layer... 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."
Voilà tout le débat en deux phrases. Certains développeurs adorent la surface structurée et relisible. Elliot Arledge, écrivant en juillet 2026, a bien défendu le point de vue favorable :
"for most important dev and contracts I've been doing, cursor is my go-to and its not even close... being able to inspect code and ensure that production systems don't get slopified is super important to me."
L'inquiétude inverse, dans une réponse sous ce même fil, est celle que je juge la plus digne d'être prise au sérieux : « I really fear losing control over my codebase » (J'ai vraiment peur de perdre le contrôle de ma base de code). Plus le coordinateur délègue, moins un relecteur seul lit réellement de lignes. Ce n'est pas une raison d'éviter Projects. C'est une raison de garder votre discipline de relecture exactement là où elle était le premier jour, surtout quand le schéma « tient » et que vous êtes tenté de survoler. Si vous comparez avec d'autres outils, nos comparatifs des alternatives à Cursor et de Cursor contre Windsurf montrent où se place chacun.
À quoi ressemble ce modèle « diriger la flotte » au-delà du code
Voici ce qui m'a le plus frappé en construisant des systèmes d'agents chez eesel : Cursor Projects est une instance propre au codage d'un schéma qui apparaît partout. Un coordinateur qui planifie et délègue, des sous-agents qui font le travail, un contexte partagé qui s'accumule, des déclencheurs qui le font tourner sans prompt. Remplacez « base de code » par « file de support » ou « pipeline de contenu » et l'architecture est la même.
C'est exactement ainsi qu'eesel est construit, simplement orienté vers d'autres métiers. eesel est une plateforme de coéquipiers IA, et vous embauchez des coéquipiers prêts à travailler pour un rôle précis plutôt qu'un bot généraliste. L'effectif actuel comprend un coéquipier IA de helpdesk et un rédacteur de blog IA, chacun arrivant avec les compétences, les intégrations et le contexte d'entreprise de son poste. Le coéquipier de helpdesk rejoint votre file existante et rédige ou résout des tickets ; le rédacteur de blog fait des recherches et écrit du contenu long comme cet article a été construit. C'est le même basculement « vous dirigez, l'agent travaille » que vend Cursor, tourné vers l'automatisation du service client et les équipes de contenu SEO plutôt que vers les pull requests.
Et comme cet article parle en réalité de workflows agentiques pilotés depuis le terminal, le parallèle avec la CLI mérite d'être précisé. Cursor vous laisse piloter des sous-agents cloud depuis votre éditeur avec des commandes comme /in-cloud et /autopilot. eesel expose le même genre de surface programmable pour ses coéquipiers : la CLI eesel (@eesel/cli) est un vrai binaire npm dont la documentation dit littéralement « everything on this site can be done from the terminal ». Vous pouvez faire eesel integrations connect, modifier les règles permanentes de l'agent avec eesel instructions, verrouiller les actions risquées avec eesel approvals et suivre chaque exécution, de la plus récente à la plus ancienne, avec eesel activity. Chaque commande affiche du JSON et prend en charge --dry-run, elle s'intègre donc directement à la CI, et chaque espace de travail est aussi un serveur MCP, branché comme n'importe quelle autre intégration MCP, ce qui signifie qu'un agent de codage comme Cursor, Claude Code ou Codex peut piloter directement votre coéquipier de support ou de contenu. Cette vue d'observabilité eesel activity correspond presque un pour un au « bring the finished work back to you to check » de Cursor.
Un point sur lequel un coéquipier de support ou de contenu doit aller plus loin qu'un coordinateur de code : vous ne pouvez pas « relire chaque PR » quand l'agent parle à un client en direct. C'est pourquoi eesel vous permet de simuler un coéquipier sur vos vrais tickets historiques avant qu'il ne réponde, et de garder les actions derrière des validations jusqu'à ce que vous lui fassiez confiance. C'est la même leçon que soulignent les sceptiques de Cursor, appliquée à un travail qui part directement vers une personne.
Essayer eesel
Si Cursor Projects vous a convaincu du modèle « diriger une flotte d'agents, ne pas les surveiller » et que vous dirigez une équipe de support ou de contenu, c'est exactement ce que fait eesel pour ces métiers. Vous branchez un coéquipier IA de helpdesk sur Zendesk, Freshdesk, Gorgias ou Slack, il apprend votre historique et votre centre d'aide et commence à rédiger et résoudre des tickets ; ou vous orientez le rédacteur de blog IA vers votre pipeline de contenu plutôt que d'assembler des outils d'écriture IA séparés. Il se pilote depuis le tableau de bord ou entièrement depuis le terminal via la CLI et le serveur MCP d'eesel, et vous pouvez le simuler sur des données réelles avant sa mise en ligne. L'essai est gratuit.
Questions fréquentes
Qu'est-ce que Cursor Projects ?
Cursor Projects, lancé le 10 septembre 2026, est une façon de mener un gros volume de travail (une fonctionnalité, une migration, de la maintenance continue) dans un seul fil Cursor. Au lieu d'ouvrir un nouveau chat par tâche, vous parlez à un agent coordinateur qui planifie le travail et le délègue à plusieurs agents exécutés en parallèle.
Combien coûte Cursor Projects ?
Il n'y a pas de prix distinct pour Projects. Il repose sur les Cloud Agents de Cursor, qui sont facturés au tarif API du modèle choisi, et il faut un forfait payant pour exécuter des agents cloud. Comme un coordinateur peut lancer de nombreux sous-agents à la fois, le coût suit l'usage, pas un tarif fixe. Consultez notre analyse complète des tarifs de Cursor pour le détail des forfaits.
En quoi l'agent coordinateur diffère-t-il d'un chat Cursor normal ?
Un chat normal fait le travail devant vous. Le coordinateur n'écrit pas de code lui-même ; il planifie, délègue à des sous-agents et vous rapporte le travail terminé pour relecture. C'est le même virage vers le codage agentique que l'on voit dans des outils comme OpenAI Codex et GitHub Copilot.
Cursor Projects peut-il tourner sans que je surveille ?
Oui. Projects utilise des « abonnements » pour que le coordinateur puisse surveiller un canal Slack, s'exécuter selon un calendrier ou suivre vos PR et réparer la CI sans prompt. C'est la même idée que les workflows d'agents automatisés ailleurs. Pour le support, les workflows de service client IA d'eesel reposent sur le même modèle piloté par des déclencheurs.
Cursor Projects est-il sûr sur une base de code de production ?
Il peut l'être, si vous gardez un humain dans la boucle. Les sous-agents peuvent travailler sur des branches isolées ou dans leurs propres VM cloud, et le coordinateur renvoie le travail terminé en relecture avant le merge. Le vrai risque est de relire moins à mesure que vous faites davantage confiance. Si vous exécutez des agents sur du travail en contact avec les clients, un outil comme eesel permet de simuler sur l'historique réel et de soumettre les actions à des validations avant tout.