Cursor ajoute un mode d'équipe à Projects : les agents des collègues partagent contexte et tâches

Si vous avez déjà essayé de lancer plusieurs agents de code en parallèle, vous savez ce que cela donne en pratique : une personne, un coordinateur, une meute de workers. Tout va bien tant que l'on travaille seul. Dès qu'un second ingénieur rejoint la tâche, chacun se retrouve avec son propre jeu de chats, son propre contexte et sa propre version de ce qui se passe réellement. C'est précisément ce problème que Cursor a voulu résoudre : Projects devient « multijoueur ».

Ce qui change

Pour rappel, Projects est un mode dans lequel l'ingénieur pilote une tâche d'envergure via un coordinateur unique, qui répartit le travail entre les agents. Auparavant, ce système ne servait qu'une seule personne. Désormais, on peut inviter des collègues dans un Project, et toute l'équipe travaille dans le même espace, avec tous les agents.

L'entreprise met en avant trois éléments.

Premier élément : un tableau de tâches partagé. On y voit qui s'occupe de quoi, sur quoi travaillent les agents de chaque participant et quelle pull request se cache derrière chaque tâche. Humains et agents regardent la même image à jour, au lieu de la reconstituer à partir de chats et de fils de discussion.

Deuxième élément : une couche de contexte commune. Chaque participant conserve un chat personnel avec le coordinateur et des workers disposant de leur contexte local. Par-dessus se trouve une base commune : exigences, schémas, spécifications techniques, maquettes. Une décision prise dans un chat devient accessible à tous les agents du projet. Lorsqu'une nouvelle personne rejoint le Project, le contexte est déjà configuré et à jour.

Troisième élément : la communication entre agents. Les coordinateurs des collègues voient ce que font leurs voisins et peuvent s'entendre sans intervention humaine.

Des exemples concrets

Cursor présente plusieurs scénarios. Le plus terre à terre concerne les astreintes (on-call). Plusieurs équipes de l'entreprise assurent la rotation dans un Project commun. Lorsqu'un ingénieur a pris le relais d'un collègue, son coordinateur a d'abord vérifié que tout était correct, puis a poursuivi là où le précédent s'était arrêté. Il savait déjà quelles tâches étaient en cours, quelles demandes restaient sans réponse, ce qu'il fallait transmettre concernant les incidents et les notes, et quels canaux, tableaux Linear et fils de discussion surveiller. Le travail inachevé peut être transmis directement : l'agent du nouvel astreignant le reprend tout simplement.

Deux autres exemples portent sur les conflits. Un ingénieur ajoute des avis sur une page produit pendant qu'un designer la refond. Les coordinateurs repèrent le chevauchement à l'avance, et les avis sont directement intégrés au nouveau design, sans refactoring ultérieur. Ou encore : votre fonctionnalité lit dans la base de données, tandis qu'un collègue modifie le schéma ; les agents s'accordent à l'avance sur l'ordre des travaux, et il n'y a pas de conflits de merge à démêler à la fin.

L'idée est claire et familière : ce qui se réglait autrefois en réunion ou par messages est confié aux coordinateurs.

Ce qu'il faut garder à l'esprit

Tout cela reste pour l'instant la description du fournisseur lui-même. Aucun chiffre : ni le temps que fait gagner le contexte partagé, ni la fréquence à laquelle les agents détectent réellement les chevauchements, ni leur taux d'erreur. Les exemples des avis et du schéma de base de données ressemblent à des illustrations plutôt qu'à des résultats de mesures. Seules les astreintes sont décrites comme une pratique réelle, et encore, au sein de l'entreprise elle-même.

Des questions restent ouvertes. Qui vérifie la couche de contexte commune, et comment, si une décision erronée y est entrée et que tous les agents la voient désormais ? Comment sont gérés les droits d'accès aux documents et aux canaux ? Que se passe-t-il si les coordinateurs se sont accordés sur un ordre alors que les humains pensent autrement ? Le blog n'y répond pas. Le mode vient en outre d'entrer en bêta.

Que faire en pratique

Si votre équipe utilise déjà Cursor, il est judicieux d'essayer un Project sur une tâche petite mais réelle impliquant deux ou trois personnes. Bons candidats : la passation d'astreinte, une fonctionnalité qui croise le travail d'un autre, l'onboarding d'un nouveau développeur. Le Project se crée dans le menu de gauche, puis on invite les collègues.

Posez-vous tout de suite deux questions. Passe-t-on moins de temps à expliquer le contexte aux nouveaux ? Le nombre de conflits de fusion a-t-il diminué ? Si les réponses sont positives, c'est le signe que la couche de contexte commune fonctionne. Sinon, c'est pour l'instant une belle idée, pas un outil de travail. Pour les product managers et les team leads, la conclusion principale est simple : la concurrence entre agents de code se déplace de « quel agent est le plus intelligent » vers « quel système organise le mieux le travail de plusieurs personnes et de plusieurs agents ensemble ».