Guide de collaboration multijoueur Cursor Projects (bêta 2026)

Depuis le 10 novembre 2026, Cursor ne réserve plus Projects au pilotage individuel : l'espace de travail devient collaboratif. Votre agent coordinateur peut échanger avec celui d'un collègue, détecter des modifications de code qui se chevauchent et transmettre une pull request inachevée. Pour l'utiliser sans risque, il faut Cursor 3.26.13 ou une version ultérieure, un compte Teams et des règles claires autour des fichiers de contexte partagés : une hypothèse non validée par un agent ne doit pas réécrire le plan de toute l'équipe dans le dépôt.

Projects passe du coordinateur unique au travail d'équipe

Cursor Multiplayer Projects fait évoluer la bêta Projects mono-utilisateur du 10 septembre 2026 vers un espace partagé où chaque membre pilote son propre chat privé avec un coordinateur, tout en utilisant le même Task Board et le même Project Agent Store (/cursor/stores/self). D'après la documentation officielle de Cursor Projects, la mise à jour du 10 novembre dissocie les voies d'exécution personnelles de l'état partagé de l'équipe selon huit dimensions clés :

Conditions d'accès et mise en place en deux étapes

Selon la documentation Cursor Projects, partager un Project multijoueur exige un compte Cursor Teams ou Enterprise, le client 3.26.13 ou ultérieur, ainsi qu'un accès individuel au dépôt pour chaque personne invitée. Le partage multijoueur n'est pas disponible avec les formules Free, Plus et Legacy Hobby. Il est également impossible d'inviter des collègues si Privacy Mode (Legacy) est activé, si le Project s'exécute sur des machines auto-hébergées, ou s'il est archivé.

Étape 1 : créer le Project de base en 4 actions

Avant d'ajouter des collaborateurs, le propriétaire initialise l'espace de travail dans la fenêtre Agents de Cursor :

1. Ouvrir Projects dans la navigation de gauche : Ouvrez la fenêtre Agents, repérez la section Projects dans la barre latérale, puis choisissez New Project.
2. Nommer le Project : Choisissez une icône et saisissez un nom précis, centré sur le résultat attendu ; laissé vide, il devient New Project. Au lieu d'un Project monolithique par dépôt, découpez-les par livrable : un pour une migration de schéma, un pour une fonctionnalité répartie sur plusieurs PR et un pour la maintenance récurrente de la CI, par exemple.
3. Choisir le workspace et le modèle coordinateur : Dans Workspace, sélectionnez le dépôt GitHub cible ; si GitHub n'est pas lié, cliquez sur Connect GitHub. Dans Model, sélectionnez le modèle qui jouera le rôle de coordinateur.
4. Cliquer sur Create Project : Cursor provisionne un ordinateur cloud pour le Project et ouvre un fil individuel avec votre agent coordinateur.

Si vous avez déjà cadré le travail dans un chat Cloud Agent principal éligible, faites glisser ce chat depuis la barre latérale sur la ligne du Project, ou ouvrez son menu latéral et choisissez Add to Project, afin que le coordinateur récupère l'historique précédent. Avec un chat local, Cursor le convertit d'abord en Remote Control.

Étape 2 : inviter des collègues en 3 actions

Une fois le Project actif et relié à un dépôt, son propriétaire ou tout membre existant peut inviter des collègues en suivant les trois étapes documentées :

1. Ouvrir le menu d'invitation : Sélectionnez Invite en haut du Project ; après la première invitation, ce contrôle devient une rangée d'avatars.
2. Inviter ou copier le lien de partage : Recherchez une personne par son nom ou son e-mail sous Invite teammates to this project, puis envoyez l'invitation. Vous pouvez aussi choisir Copy link afin de partager l'URL du Project dans Slack ou Linear.
3. Accepter l'invitation et obtenir un chat dédié : La personne invitée clique sur Accept Invite dans la carte d'invitation du Project. Elle reçoit son propre chat Project, son agent coordinateur et un accès en lecture-écriture au contexte partagé.

Gérer les membres et les liens

Les limites d'accès sont appliquées à la fois au niveau de l'équipe Cursor et de celui du dépôt Git :

• Même équipe, même dépôt : Les utilisateurs de comptes personnels et les développeurs d'équipes Cursor externes ne peuvent pas rejoindre le Project. Chaque personne invitée doit par ailleurs disposer de son propre accès au dépôt concerné.
• Révoquer un lien diffusé trop largement : Seuls les membres existants du Project peuvent copier le lien d'invitation. Si celui-ci circule au-delà du nécessaire, le propriétaire peut ouvrir le menu d'invitation et sélectionner Reset Share Link pour invalider toutes les copies précédentes.
• Quitter ou retirer un membre : Tout participant peut sélectionner Leave Project dans le menu latéral, puis revenir plus tard avec une invitation ou un lien valide. Le propriétaire peut retirer un participant via Remove dans le menu d'invitation.

Contexte partagé (/cursor/stores/self) ou store personnel (/cursor/stores/user)

Comme le précise la documentation Cursor Projects Context and Personal Store, Cursor Multiplayer Projects sépare la configuration privée d'un développeur des connaissances communes à l'équipe en montant deux chemins de système de fichiers distincts dans l'environnement de chaque agent : /cursor/stores/self pour le contexte partagé du Project et /cursor/stores/user pour le store utilisateur personnel. Selon les règles officielles, lorsqu'un collègue rejoint un Project partagé, son coordinateur peut proposer de copier des préférences de travail pertinentes de /cursor/stores/user dans les règles du Project ; seules les entrées explicitement approuvées par l'utilisateur sont copiées.

Comment les coordinateurs échangent via des discussions latérales non fiables

Lorsqu'un coordinateur a besoin d'informations sur le travail d'un collègue, la spécification multijoueur de Cursor Projects l'autorise à contacter directement le coordinateur de ce collègue en créant, depuis son chat normal, une discussion latérale dérivée nommée Chat with {name}'s agent. Cursor limite les actions possibles dans cette discussion afin qu'une requête entrante n'interrompe pas le fil actif du destinataire et ne puisse pas exfiltrer de secrets.

Dans l'annonce multijoueur de Cursor du 10 novembre 2026, le product manager Aryaman Khandelwal a présenté deux scénarios majeurs de coordination entre agents :

• Chevauchement entre UI et fonctionnalité : Un ingénieur ajoute des avis clients à une page produit pendant qu'un designer refond cette même page. Leurs coordinateurs détectent tôt le recouvrement et intègrent le composant d'avis à la nouvelle mise en page plutôt que de devoir le refactorer plus tard.
• Ordonnancement du schéma et des lecteurs : Un développeur modifie un schéma de base de données tandis qu'un collègue construit une fonctionnalité qui lit cette base ; leurs agents conviennent en amont de l'ordre des opérations pour éviter un conflit d'intégration au moment du merge.

Comme l'indique la section How coordinators message each other des docs officielles de Cursor Projects, cet échange obéit à quatre règles strictes :

1. Requête sortante : Le coordinateur du collègue A identifie une dépendance envers le travail du collègue B et contacte directement le coordinateur de B.
2. Création d'une discussion latérale dérivée : Le message entrant crée un chat dérivé du chat normal du collègue B, nommé Chat with {Teammate A}'s agent.
3. Évaluation comme contenu non fiable : Les messages entrants des coordinateurs sont étiquetés comme des entrées d'agent. Le destinataire est informé de l'agent du collègue expéditeur et traite le message comme un élément non fiable à évaluer, non comme une demande directe de son propre utilisateur.
4. Réponse avec le savoir du chat principal et notification au tour suivant : La discussion latérale répond à partir des connaissances disponibles dans le chat principal du destinataire, puis transmet la réponse au coordinateur émetteur. Le chat principal du collègue B n'est pas interrompu immédiatement : il reçoit une note sur cet échange à son tour suivant.

La documentation Cursor Projects définit les limites d'autorisation exactes de chaque discussion latérale Chat with {name}'s agent :

Du plan à la livraison : les failles de décision de la bêta

Les exemples officiels de Cursor mettent en avant les rotations d'astreinte, où le coordinateur de l'ingénieur entrant récupère les incidents en cours, les tableaux Linear et les fils Slack. Mais les retours sur la bêta Projects en solo font ressortir quatre défaillances opérationnelles tout au long des quatre étapes du cycle de vie ; elles imposent des garde-fous en équipe :

Project Notes modifiables : le risque des erreurs partagées

Dans un test terrain individuel de 3 jours de la bêta Cursor Projects, publié sur le Cursor Community Forum et couvrant 5 sessions, environ 14 heures, 20 agents, 32 tâches, 49 tours d'agent et 5 pull requests dont 4 fusionnées, le développeur Lutz Leonhardt a examiné le dossier de contexte synchronisé et les transcriptions de l'orchestrateur. La délégation et la livraison ont bien fonctionné, avec la correction des 18 problèmes signalés par un bot de revue Codex. La couche de mémoire du Project a toutefois révélé deux défaillances qui deviennent encore plus risquées dans un store multijoueur partagé :

• 111 réécritures de notes pour 1 lecture explicite : Au cours du test de 3 jours, le coordinateur a réécrit le fichier Project Notes 111 fois en remplaçant le fichier entier, mais ne l'a lu explicitement qu'une seule fois. Le jalon 1 avait disparu des notes avant le début de l'archivage, le deuxième jour ; une validation explicite concernant l'analyse LLM de podcasts a été réduite à "done" après deux réécritures. Le coordinateur a donc redemandé la même validation le lendemain.
• Des valeurs par défaut non approuvées enregistrées comme décisions : Après avoir listé 5 mots-clés et 3 questions ouvertes, le développeur a interrogé le coordinateur au sujet d'une clé API et sur le possible démarrage du jalon 2. Le coordinateur a interprété des valeurs par défaut non confirmées comme "accepted for the start" et lancé un agent qui a implémenté un adaptateur cron toujours actif, en contradiction avec son propre conseil précédent. Dans un autre échange, le coordinateur a nié avoir reçu un relais de worker qu'il avait déjà exécuté, puis a inscrit cette fausse chronologie comme règle de workflow dans le dossier de contexte.

Le rapport de Leonhardt portait sur Projects en solo. En multijoueur, les agents de chaque collègue lisent et écrivent dans /cursor/stores/self : une note polluée ou une valeur par défaut d'agent non vérifiée peut donc influencer n'importe quel agent d'équipe qui lit ensuite le store partagé. Comme l'a relevé le développeur @avisinghdotdev sur X après le lancement multijoueur :

"Honnêtement, je n'aime pas l'idée qu'un agent parle avec l'agent de mon collègue, surtout s'ils ont des ensembles de règles et de compétences distincts. Une seule production bâclée peut dégrader la qualité." — @avisinghdotdev

Garde-fou recommandé pour les Projects multijoueur : Ne laissez pas les coordinateurs utiliser un unique fichier Markdown modifiable dans /cursor/stores/self à la fois comme bloc-notes et registre de décisions. Configurez les règles du Project pour séparer l'état en deux fichiers :

1. Un plan.md modifiable pour l'état des tâches et les pointeurs de branches actives.
2. Un decisions.md commité dans le dépôt et régi par une règle d'agent en ajout uniquement, avec revue des diffs Git ou protection de branche quand une application stricte est nécessaire. Il doit enregistrer date, decided_by (human:@handle ou agent:proposed), status (proposed, accepted, superseded), applies_to (glob de chemin de fichier) et une rationale d'une ligne.

Checkouts obsolètes, MCP cloud et relais via worktrees locaux

La deuxième série de problèmes de la bêta vient de l'architecture d'exécution cloud par défaut de Cursor. À partir de retours utilisateurs vérifiés dans le rapport Day 7 sur Cursor Projects et de fils r/cursor, quatre pièges opérationnels concernent les équipes qui adoptent Projects :

1. Checkouts Git obsolètes dans les Projects de longue durée : Un Project cloud persistant ne récupère pas automatiquement les changements fusionnés depuis main (rapport Day 7 R1 ; le personnel de Cursor a confirmé qu'il s'agit du comportement attendu et a conseillé de demander un pull au coordinateur). En multijoueur, demandez systématiquement à votre coordinateur d'exécuter git pull avant de déléguer de nouvelles tâches.
2. Chargement des serveurs MCP uniquement depuis le cloud : Le coordinateur étant un Cloud Agent, il lit uniquement les serveurs Model Context Protocol (MCP) configurés dans les paramètres cloud Cursor (rapport Day 7 R6). Les serveurs MCP configurés seulement dans votre éditeur desktop local ne sont pas chargés dans le coordinateur du Project.
3. Le piège du réglage « No self-hosted workers available » : Pour exécuter des tests locaux depuis un Project cloud, activez Remote Control, soit les workers locaux auto-hébergés, dans Settings > Agents, puis lancez agent login suivi de agent worker start à la racine du dépôt. Activer Remote Control peut toutefois aussi activer Self-hosted Machines et l'option Require Self-hosted Machines and Personal Machines dans le tableau de bord de l'équipe. Cette option bloque les Cloud Agents et Projects dans le cloud de Cursor. Les administrateurs doivent désactiver ce réglage Require pour conserver une exécution hybride cloud/local.
4. Consommation de tokens cloud : Exécuter 10 à 20 sous-agents cloud en parallèle consomme rapidement l'usage inclus dans l'abonnement. Comme l'a signalé l'utilisateur r/cursor u/Shirc sur Reddit :

"Projects a du potentiel, mais pour l'instant c'est un peu le bazar et ça va dévorer les tokens." — u/Shirc dans r/cursor

Pour limiter cette consommation dans ce même fil r/cursor, le développeur u/dryu12 conseille de choisir Composer comme modèle coordinateur et d'écrire des règles explicites sur les modèles attribués à chaque tâche déléguée. Si l'équipe utilise aussi des bots de revue CI externes ou des scripts d'agents personnalisés hors de la facturation intégrée de Cursor, faire passer ces appels API par AIReiter permet d'associer des modèles économiques comme DeepSeek V4.1 Flash à des reviewers comme Claude Opus 5.5 sur un solde unique à l'usage.

Conflits de revue : chaque pull request doit avoir un propriétaire

D'après la documentation sur les abonnements de Cursor Projects, dès qu'au moins 1 abonnement existe — surveillance d'un canal Slack, de l'activité d'une PR, des exécutions CI d'une branche ou d'un horaire tel que every day at 8:00 AM — une pastille Listening apparaît au-dessus du champ de saisie du chat.

Dans le test individuel de 3 jours de Leonhardt, le traitement des revues de PR était déjà ambigu : le coordinateur, le worker auteur de l'implémentation initiale et les agents correctifs créés ensuite pouvaient tous réagir aux événements de revue. Sur une PR, le coordinateur a demandé deux fois à l'auteur des correctifs que l'agent initial était déjà en train d'apporter ; sur une autre, 3 agents ont réécrit le même fichier d'état en laissant le mauvais auteur enregistré.

Lorsque plusieurs collègues font tourner des coordinateurs dans le même dépôt, abonner plusieurs coordinateurs aux événements de PR de l'ensemble du dépôt augmente le risque de commits correctifs dupliqués et de tours cloud gaspillés. Comme l'a résumé le développeur @LabubuNoBB sur X :

"Le problème n'a jamais été de faire communiquer les agents. Le vrai sujet, c'est de savoir qui possède quoi lorsque deux d'entre eux veulent modifier le même fichier." — @LabubuNoBB

Règle recommandée de propriété des PR : Attribuez un propriétaire humain et un agent désigné à chaque PR dans le Task Board partagé, y compris la responsabilité de tous les commentaires de revue sur cette branche. Limitez les abonnements du coordinateur de chaque collègue à ses propres PR plutôt qu'à des jokers couvrant tout le dépôt.

Choisir entre Project partagé et chats séparés

Avant de transférer un workflow d'équipe dans un Cursor Project partagé, confrontez la structure de vos tâches aux contraintes vérifiées de la bêta 3.26.13+ :