Agent IA code : Cursor Projects organise le travail en file de revue

Cursor Projects change l’unité de travail de l’agent IA code : on ne part plus d’un prompt, mais d’une file de revue. Le 10 septembre 2026, Cursor a lancé en bêta un coordinateur, un contexte de projet partagé et des déclencheurs récurrents. Les équipes peuvent ainsi déléguer sans lancer chaque tâche à la main ; le goulot d’étranglement se déplace vers le cadrage, le contrôle et la décision de fusionner ou non.

Cet article décrypte le fonctionnement de l’outil pour les responsables d’ingénierie, les fondateurs techniques et les dirigeants d’agence. La vraie question n’est pas de savoir combien d’agents Cursor peut lancer. Il faut plutôt déterminer si l’équipe saura absorber le travail livré sans perdre la maîtrise des coûts ni de la qualité.

Cursor Projects : de quoi s’agit-il vraiment ?

Un Cursor Project est un espace persistant consacré à un ensemble de travaux : une fonctionnalité, une migration ou même une application complète. Il comprend un agent coordinateur, qui tient ici le rôle de chef d’orchestre. Celui-ci planifie et délègue l’implémentation, mais n’écrit pas lui-même le code.

Le code est produit par des agents d’implémentation sur des machines cloud. Le coordinateur peut en créer plusieurs, exécuter les tâches en parallèle, puis vous soumettre les résultats pour contrôle. Si un test doit tourner sur votre propre machine, il peut aussi y démarrer un agent local.

Deuxième composant : le contexte partagé. Chaque Project conserve des fichiers synchronisés entre le cloud et les machines locales utilisées par ses agents. Ils peuvent rassembler les recherches, les livrables, la connaissance de la base de code, les consignes de test et les règles de travail de l’équipe.

Le passage de relais change donc de nature. Un nouvel agent n’a plus à retrouver à chaque exécution la commande de test ou la frontière entre les services, à condition que le contexte enregistré dans le Project soit exact et à jour.

Troisième composant : les abonnements. On peut demander à un Project de surveiller un canal Slack, de s’exécuter selon un calendrier ou de suivre des pull requests. Lorsqu’un signal correspond aux critères, un nouveau travail délégué peut démarrer sans qu’une personne rédige un autre prompt.

Les agents récurrents ne sont pas une nouveauté chez Cursor. Dès la version du 19 août, les Cloud Agents pouvaient surveiller les pull requests, les fils Slack et les calendriers. Projects rassemble désormais ces tâches récurrentes sous un même coordinateur et leur donne un contexte partagé, capable de suivre un flux de travail plus long.

C’est là que réside la vraie nouveauté. Cursor n’ajoute pas simplement une énième interface de chat pour coder : il donne un espace durable au travail délégué.

Pourquoi l’agent IA code déplace le goulot vers la revue

Le contexte partagé peut éviter de répéter la configuration. Cursor n’a publié aucun chiffre d’accélération et cette bêta est trop récente pour en établir un. Il est donc prématuré d’inscrire des heures économisées dans un budget.

Le changement concret concerne la répartition du temps de l’équipe. Un coordinateur peut lancer plusieurs chantiers d’implémentation en parallèle, tandis qu’un seul reviewer continue de lire les modifications l’une après l’autre. Ce décalage peut transformer un backlog vide en file de pull requests bien remplie.

Cette file est utile lorsque les tâches sont étroites, les tests fiables et les décisions du reviewer rapides. Elle coûte cher quand les agents renvoient des diffs trop larges, du travail en double ou des modifications dont l’intention reste floue. Une production parallèle demeure du stock tant que personne ne l’a acceptée.

Tous les utilisateurs de Cursor ne sont pas touchés de la même façon. Un développeur indépendant qui traite une seule tâche bien délimitée à la fois tirera peut-être peu d’un coordinateur. Une équipe dont les tests sont fragiles ou qui n’a désigné aucun reviewer risque de produire davantage d’incertitude que de débit. Pour une équipe qui utilise déjà les automatisations récurrentes des Cloud Agents, le principal bénéfice vient du contexte partagé du Project, pas du déclencheur lui-même.

À qui s’adresse-t-il, et qu’est-ce qui change ?

Un responsable d’ingénierie SaaS qui pilote une migration

Confiez à un Project une migration bien délimitée, avec des exclusions explicites, les commandes de test, les règles de déploiement et la répartition des responsabilités. Le coordinateur peut répartir les modifications mécaniques entre plusieurs agents d’implémentation, pendant que le responsable contrôle l’ordre des opérations et les points à risque.

Le gain tient à la continuité entre plusieurs branches. Il faut mesurer les modifications acceptées et le temps de revue, pas l’activité des agents.

Un directeur technique d’agence qui gère les projets clients

Réunissez les notes de configuration, les conventions de code, les chemins de test et les règles de livraison d’un client dans le contexte partagé de son Project. Les opérations de maintenance récurrentes pourront repartir des mêmes consignes, sans nouveau prompt d’onboarding.

Le bénéfice est de réduire les briefings répétés. La séparation entre clients constitue toutefois une limite absolue : le contexte et les identifiants d’un compte ne doivent jamais alimenter un pot commun avec ceux d’un autre.

Un responsable du support technique qui surveille les bugs entrants

Connectez un canal Slack public dédié aux signalements de bugs et appliquez une règle de qualification stricte. Un rapport accompagné d’étapes reproductibles peut entrer dans le Project ; les questions, les doublons et les incidents propres à un compte restent confiés à une personne.

Le résultat attendu est une branche préparée avec les éléments nécessaires à la revue, pas une fusion automatique. Dans la documentation actuelle sur les Automations, Cursor limite les déclencheurs Slack aux canaux publics. L’annonce de Projects ne publie aucune autre matrice de prise en charge des canaux.

Une équipe plateforme chargée d’une maintenance récurrente

Un Project peut conserver les consignes de test et la cartographie des services d’un flux de maintenance répétitif. Le coordinateur suit alors des pull requests ou un calendrier, puis transmet le travail d’implémentation à un responsable désigné.

Le gain est une boucle opérationnelle stable. Une équipe soumise à des contraintes réglementaires devrait attendre que son audit de sécurité couvre l’environnement cloud, le contexte synchronisé, les secrets et les contrôles de la bêta.

Lancer un pilote d’équipe bien cadré

Cursor n’a publié ni API Projects ni guide de configuration détaillé. Un pilote honnête doit donc s’appuyer sur l’interface visible de la bêta et sur les contrôles apparentés des Cloud Agents qui sont documentés aujourd’hui.

1. 1

   Vérifier l’accès et la facturation

   Cherchez Projects dans la barre de navigation gauche de Cursor. L’annonce indique un déploiement progressif de la bêta auprès de tous les utilisateurs, mais les Cloud Agents nécessitent toujours un forfait payant. Pour un pilote d’équipe, vérifiez l’activation de la fonctionnalité sur le compte concerné, confirmez le type de licence et fixez une limite de dépenses pour toute l’équipe avant d’ajouter un déclencheur récurrent.

2. 2

   Choisir une tâche reproductible

   Retenez un seul dépôt et une seule catégorie de tâches à faible risque, avec une ligne d’arrivée claire. Les bons candidats disposent d’une commande de test connue, d’un périmètre de diff réduit et d’un responsable capable d’évaluer le résultat. Écartez du premier essai les migrations qui dépendent encore de décisions produit, les modifications d’autorisations et les incidents de production.

3. 3

   Rédiger le contexte opérationnel partagé

   Fournissez au Project la cartographie du dépôt, les étapes de configuration, les commandes de test, la définition du travail terminé, les zones interdites et la règle d’escalade. Considérez ces fichiers comme des documents opérationnels à maintenir. Un contexte partagé erroné ne fait que répéter plus efficacement la même erreur.

4. 4

   Ajouter une seule voie d’entrée

   Choisissez un calendrier, un abonnement aux pull requests ou un canal Slack. Précisez quels signaux sont recevables, ce que le coordinateur peut déléguer, quelles preuves il doit rapporter et dans quels cas il doit s’arrêter sans modifier le code.

5. 5

   Attribuer la file de revue

   Désignez un seul reviewer senior. Exigez le diff, la sortie des tests et les livrables pertinents avant qu’une modification puisse avancer. Pendant la bêta, gardez le droit de fusion en dehors du Project.

6. 6

   Mesurer le travail qui passe la revue

   Suivez les tâches lancées, les modifications acceptées, les minutes de revue, les reprises, les défauts passés en production et l’usage des modèles. Comparez ces chiffres à ceux de la même catégorie de tâches avant le pilote. Ne confondez pas nombre d’agents et productivité.

Chiffrer le pilote, temps de revue compris

Le tarif de base est facile à identifier. Teams Standard coûte $40 par utilisateur et par mois : quatre nouvelles licences reviennent donc à $160 pour un cycle de facturation. Teams Premium coûte $120 par utilisateur et par mois et comprend cinq fois l’usage de Standard. Mais l’acheter avant que le pilote n’ait produit ses propres données d’usage reviendrait à sauter l’étape la plus instructive du test.

La part variable est moins lisible. Les Cloud Agents sont facturés au tarif API du modèle sélectionné. Pour Teams et Enterprise, Cursor ajoute un Cursor Token Rate de $0.25 par million de tokens éligibles provenant de modèles tiers, qu’il s’agisse d’entrée, de sortie ou de cache. L’usage à la demande est activé par défaut pour Teams, et les administrateurs peuvent définir un plafond mensuel à l’échelle de l’équipe.

Voici un modèle volontairement borné, dans lequel chaque volume de travail est explicitement présenté comme une hypothèse :

• Hypothèse de périmètre : un dépôt, un déclencheur et au maximum 20 tâches arrivant jusqu’à la revue.
• Hypothèse d’usage : chaque tâche complète, activité du coordinateur et des agents d’implémentation comprise, consomme 100,000 tokens d’entrée hors cache, 400,000 tokens lus depuis le cache et 20,000 tokens de sortie avec Claude Sonnet 5, sans token d’écriture en cache.
• Hypothèse de revue : un reviewer senior réserve 20 minutes par tâche renvoyée, pour un coût chargé de $100 par heure.

Aux tarifs actuels de Claude Sonnet 5 chez Cursor, une tâche ainsi modélisée coûte $0.20 en entrée, $0.08 en lectures du cache et $0.20 en sortie. Le tarif de tokens Teams ajoute $0.13 sur les 520,000 tokens éligibles. L’usage modélisé atteint donc $0.61 par tâche, soit $12.20 pour 20 tâches.

La revue constitue le poste principal. Vingt tâches à raison de 20 minutes chacune mobilisent 400 minutes, soit 6 heures 40 minutes. Au coût horaire supposé de $100, cela représente $666.67 de temps de reviewer.

Ajoutez $160 pour quatre nouvelles licences Standard et, en comptant l’usage modélisé même s’il ne devient pas un dépassement, le budget prévisionnel brut du mois s’élève à $838.87. Ce n’est pas une estimation de facture. Les licences existantes suppriment l’achat de $160, l’usage inclus peut absorber les $12.20, et le travail réel dans Projects peut consommer davantage de tokens puisque le coordinateur peut déléguer à plusieurs agents.

L’objectif de ce modèle n’est pas d’affirmer que la revue coûte toujours $666.67. Il consiste à lui réserver une ligne budgétaire. Adaptez le nombre de tâches, le nombre de minutes et le coût chargé à votre équipe avant de qualifier ce pilote de bon marché.

Pour replacer ce choix de produit et d’abonnement dans son contexte, notre test complet de Cursor détaille l’éditeur, les Cloud Agents, les tarifs et les mécanismes de revue existants.

Ce qu’il faut regarder en face

Premièrement, il s’agit du déploiement d’une bêta, pas d’un standard opérationnel stabilisé. L’annonce cite la navigation de gauche, mais ne fournit ni matrice d’accès propre à Projects, ni ventilation de l’usage, ni contrôle de concurrence, ni engagement de service. La fonctionnalité peut devenir disponible avant la documentation nécessaire aux achats.

Deuxièmement, le contexte partagé transporte aussi bien les consignes périmées que les bonnes. Une note de test exacte le mois dernier peut induire en erreur tous les agents futurs après une évolution du dépôt. Attribuez des responsables, des dates de revue et des règles de suppression aux fichiers de contexte.

Troisièmement, le coordinateur vous remet le travail pour contrôle. C’est le contrat du produit. Il ne remplace ni la revue humaine, ni les tests exécutables, ni les contrôles de sécurité, ni la responsabilité de la fusion.

Quatrièmement, c’est toujours l’environnement qui détermine si un agent peut prouver son travail. Les Cloud Agents ont besoin des dépôts, dépendances, secrets, commandes de démarrage et accès réseau nécessaires à la tâche. Quand la construction d’un environnement échoue, le dernier Build réussi reste actif. Un environnement incomplet peut néanmoins produire du code plausible sans preuve valide.

Enfin, chaque Project s’exécute sur une machine cloud ; des agents locaux prennent le relais lorsque les tests doivent être réalisés sur une machine précise. Les équipes soumises à des contraintes de réseau privé doivent inclure cette frontière dans leur audit. Cursor Self-Hosted Machines peut déplacer l’exécution des outils vers des workers gérés par le client, mais la boucle d’agent Cursor et le traitement par le modèle restent dans le cloud de Cursor.

Que faire maintenant ?

Agissez cette semaine si l’équipe dispose de tâches répétées et testables, d’un compte Cursor payant où la bêta est visible et d’un reviewer senior qui a de la place dans sa file. Commencez avec des licences Standard, un dépôt, un déclencheur et un plafond de dépenses strict.

Attendez si Projects n’est pas visible, si le dépôt ne peut pas exécuter ses contrôles dans un environnement Cloud Agent ou si personne ne prend en charge la revue. Même recommandation si les achats exigent un document d’accès ou de facturation propre à Projects que Cursor n’a pas publié.

L’impact restera faible si le travail n’est pas récurrent, si les sessions d’agents disposent déjà d’un contexte suffisant ou si l’exécution locale est indispensable. Le coordinateur ne mérite sa place que lorsque la continuité entre plusieurs tâches déléguées constitue le véritable goulot d’étranglement.

La décision à prendre lundi est simple : sélectionnez une catégorie de tâches récurrentes, limitez le pilote à 20 éléments révisables, nommez un reviewer, fixez le plafond de dépenses de l’équipe, puis relevez pendant un cycle de facturation les modifications acceptées, les minutes de revue, les reprises, les défauts et l’usage réel. Ne conservez Projects que si le résultat validé améliore le workflow après prise en compte de la facture des modèles et de la file humaine.

Recevez dans la newsletter le prochain décryptage opérationnel d’un workflow IA.