Cursor lance Team Projects : les agents d'une équipe partagent leurs plans et détectent les conflits

Un seul agent dans un dépôt, c'est presque de la magie. Trois à cinq agents de personnes différentes dans le même dépôt, c'est déjà de la logistique. Chacun a reçu sa tâche, chacun réécrit le code avec assurance, et personne ne sait ce que font les autres. Cursor a lancé Team Projects en bêta précisément pour combler cette lacune.

Quel problème est visé

Tant que l'assistant IA était une sorte d'autocomplétion intelligente, la coordination n'était pas nécessaire : l'humain regardait le résultat et décidait lui-même quoi faire. Quand les agents ont commencé à prendre en charge des tâches entières et à travailler pendant des minutes, voire des heures, le problème a changé. Désormais, ils entrent en conflit non pas dans l'éditeur, mais dans les branches, et ne s'en aperçoivent qu'au moment du merge, quand refaire le travail coûte le plus cher.

Imaginez : Anna demande à son agent de renommer le modèle User en Account. Pendant ce temps, Boris demande à son agent d'ajouter à User un champ de facturation. Les deux agents travaillent vite et proprement, et se rendent mutuellement inutiles. Le conflit surgira lors de la revue, voire en production.

Ce que promet Cursor

L'annonce met en avant quatre idées :

• Un contexte commun pour toute l'équipe. L'agent connaît non seulement votre tâche, mais aussi le cadre du projet dont elle fait partie.
• Des plans avant le démarrage. Les agents partagent ce qu'ils comptent faire avant de commencer.
• Des alertes de conflit en cours de route. Si les plans ou les modifications se recoupent, cela se voit tout de suite, et non au moment du merge.
• De l'aide au déblocage. Un agent peut indiquer à un autre ce qui l'empêche d'avancer dans sa tâche.

Dans notre exemple, l'agent de Boris verrait le plan d'Anna avant le démarrage. Il attendrait alors le renommage, ou bâtirait directement sa modification sur le nouveau nom. Ce scénario est illustré par nos soins et n'est pas tiré du billet de Cursor, mais c'est bien ce type de problème que décrit l'annonce.

Ce que nous ne savons pas encore

Le billet est court : c'est une annonce de bêta avec un lien vers des détails. Plusieurs points importants n'y apparaissent pas :

• où et comment le contexte commun est stocké, et qui y a accès ;
• comment les conflits sont résolus : les agents s'accordent-ils entre eux ou font-ils appel à un humain ;
• combien cela coûte et quelles sont les limites de la bêta ;
• si la coordination ne fonctionne qu'avec les agents Cursor ou plus largement.

Il est donc trop tôt pour évaluer l'utilité réelle. Bêta signifie que le comportement peut changer et que les cas limites ne sont pas encore traités.

Que faire de tout cela

Si votre équipe lance déjà plusieurs agents en parallèle, c'est une bonne occasion de mener un pilote. Prenez un petit projet et comptez avant et après : combien de merges conflictuels, combien de reprises après revue, combien de temps les tâches restent en attente. Si les chiffres ne s'améliorent pas, le contexte commun ne justifie pas sa complexité.

Vérifiez séparément les questions de sécurité : quel code et quels plans arrivent dans l'espace partagé, et quels participants peuvent les voir. Pour les entreprises soumises à des exigences strictes sur les données, cela peut devenir le critère principal.

Les équipes produit devraient s'intéresser à l'idée elle-même : les plans des agents deviennent un artefact que l'on peut lire et discuter avant l'écriture du code. C'est un point de contrôle peu coûteux. Il ne remplace pas la revue humaine, mais peut éviter certaines mauvaises surprises.

Pour les fondateurs, le signal est le suivant : le marché des outils passe de l'agent pour un seul développeur à la coordination des agents au sein d'une équipe. Celui qui résoudra ce problème de façon fiable décrochera des contrats d'équipe. Le premier pas de Cursor semble logique, mais il faut le tester sur de vrais dépôts, et non à partir d'un seul billet.