Qu'est-ce qu'un agent en arrière-plan Cursor ?
D'abord le nom : la documentation de Cursor indique que « les Cloud Agents s'appelaient autrefois Background Agents ». Même produit, nouveau nom — nous utilisons les deux dans ce guide. [3] Un agent en arrière-plan est un agent de code qui tourne pendant une longue période loin de votre ordinateur portable : la tâche part dans le cloud, et un agent la mène du début à la fin sans interruption, puis rend compte avec des preuves que le travail est fait. [1]
Chacun tourne sur sa propre machine virtuelle dédiée avec un environnement de développement complet — votre dépôt, vos dépendances, vos secrets et un accès réseau. L'agent planifie la tâche, modifie le code, exécute des commandes et teste son travail pendant des minutes ou des heures, et continue que votre machine soit en ligne ou non. [1] La VM est confinée (sandbox) et isolée de votre machine locale, et vous contrôlez quels dépôts, secrets et accès réseau un environnement reçoit. [1]
Une fois le travail terminé, l'agent ouvre une pull request — et montre son travail. Pendant qu'il tourne, il joint des captures d'écran, des vidéos et des références de logs à la PR afin que vous puissiez valider les changements sans récupérer la branche. [1] Les Cloud Agents peuvent même piloter leur propre bureau et navigateur, en cliquant à travers des parcours d'interface pour vérifier que ce qu'ils ont construit fonctionne vraiment avant de pousser. [2]
Cinq façons d'en lancer un
Vous pouvez lancer un Cursor Cloud Agent depuis l'endroit où vous travaillez déjà : [3]
Dans Cursor Desktop
Sélectionnez Cloud à côté du champ de saisie de l'agent et donnez-lui la tâche.
Sur le web ou sur iPhone
Démarrez et gérez des agents depuis Cursor Web (cursor.com/agents) ou Cursor pour iOS.
Depuis l'endroit où vit le travail
Mentionnez @Cursor sur Slack, sur un ticket ou une PR GitHub ou Bitbucket, ou assignez-lui un ticket Linear.
Avec Automations
Faites tourner des agents sur un planning (cron) ou sur des événements GitHub, GitLab, Slack, Linear et webhooks.
Depuis votre propre code
Démarrez et gérez des agents de façon programmatique via l'API.
Les Automations sont documentées séparément. [4] Avant que quiconque puisse lancer un agent depuis un dépôt, un administrateur du compte Cursor connecte la gestion de code source : GitHub (Cloud et Enterprise Server), GitLab (Cloud et Self-Hosted), Bitbucket Cloud, ou Azure DevOps. [3]
Pourquoi en faire tourner plusieurs est la partie difficile
La fonctionnalité phare est facile à manquer : vous pouvez faire tourner autant d'agents que vous voulez en parallèle, et aucun n'a besoin que votre machine locale soit connectée. [3] Le parallélisme est tout l'intérêt. Un seul agent en arrière-plan est une commodité agréable ; cinq qui tournent en même temps, c'est un changement d'échelle dans ce qui est livré chaque semaine.
Mais des agents en parallèle changent la nature du goulot d'étranglement. Les agents peuvent coder jour et nuit — ce qu'ils ne peuvent pas faire, c'est décider ce qui vaut la peine d'être fait, dans quel ordre, et si le travail est réellement terminé. Chaque agent ajouté consomme un peu plus votre attention, précisément quand vous êtes le plus occupé : cadrer la prochaine tâche, relire une PR qui vient de se terminer, repérer un agent qui a dérivé. À en faire tourner trop sans les gérer, vous passez votre journée à naviguer entre tableaux de bord plutôt qu'à piloter le produit.
Il y a un deuxième échec, plus discret : la qualité. Un agent qui tourne sans surveillance pendant une heure construira volontiers, et magnifiquement, la mauvaise chose si la consigne était vague. Avec un agent, vous le remarquez. Avec dix, des consignes vagues deviennent silencieusement dix pull requests erronées.
Et ces pull requests erronées coûtent de l'argent réel. « Les Cloud Agents sont facturés au tarif API du modèle choisi… une fenêtre de contexte plus large peut augmenter l'usage de tokens et les coûts. » [3] Le parallélisme multiplie cette facture — une story vague n'est donc pas seulement du temps de revue gâché, ce sont des tokens dépensés à construire la mauvaise chose, plusieurs fois.
La compétence qui compte avec les agents en arrière-plan n'est donc pas de les lancer — Cursor a réduit cela à une simple mention. C'est de les nourrir. Les équipes qui tirent le plus des agents en parallèle sont celles qui savent écrire un travail assez précis pour tourner sans surveillance, et qui gardent un œil sur chaque agent en cours sans s'attarder sur aucun. Combien vous pouvez réellement suivre est surtout une question de capacité de revue.
Les pratiques qui gardent une flotte saine
Rédigez la story avant d'envoyer
Donnez à chaque agent un périmètre clair et des critères d'acceptation, pas une impression. Une story précise avec une définition du « terminé » tourne sans surveillance ; une story floue revient fausse.
Gardez la file au même endroit
Planifiez dans un outil de suivi comme Linear pour toujours savoir ce qui est en file, ce qui tourne et ce qui est bloqué — pas dispersé entre des fils Slack et des onglets de terminal.
Laissez les agents prendre leur propre travail
Une fois vos stories suffisamment bonnes, les agents peuvent être lancés directement depuis le ticket auquel ils appartiennent — dans Linear, Slack ou GitHub — plutôt que vous ne copiiez-colliez des prompts un par un.
Surveillez la dérive, pas seulement l'achèvement
Un agent qui tourne deux heures sur le mauvais problème coûte plus cher qu'un agent qui finit vite sur le bon. Repérez la dérive de périmètre tôt, pas seulement à la PR.
Faites confiance aux preuves, vérifiez les bords
Les agents joignent captures d'écran, vidéos et logs à leurs PR — utilisez-les pour relire vite sans récupérer chaque branche, et creusez seulement où c'est important.
Utilisez des environnements multi-dépôts quand le travail touche plusieurs services
Pour des tâches qui touchent le frontend, le backend et des bibliothèques partagées en un seul run, un environnement multi-dépôts permet à un agent de voir et changer tout le tableau.
Une remarque sur cette dernière pratique : les environnements multi-dépôts permettent à un seul agent de travailler sur des dépôts frontend, backend, infrastructure ou bibliothèques partagées séparés, et d'ouvrir des pull requests dans chaque dépôt qu'il modifie. [3] Mais même le meilleur environnement multi-dépôts ne travaille qu'une tâche à la fois — décider quelle doit être la story au niveau architecture, sur tous ces dépôts, reste votre travail. Pour savoir comment l'écrire, voir notre guide sur les stories pour agents de code.
Cursor s'intègre déjà à Linear — pourquoi aller plus loin ?
Bonne question. Vous pouvez assigner un ticket Linear à @Cursor et un Cloud Agent le prend en charge, [5] et Automations peut lancer des agents à partir d'événements GitHub, Linear ou Slack. [4] Cursor est un très bon moteur. Ce qu'il ne fait pas, c'est décider quoi exécuter, ni dans quel ordre — il exécute le ticket que vous lui donnez, quand vous le lui donnez.
C'est le vide qu'Aerunit comble. Pensez à Cursor comme au moteur et à Aerunit comme au répartiteur : il rend le ticket digne d'être exécuté, l'envoie quand il est prêt à tourner, et renvoie les remarques de revue à la même session d'agent pour correction.
Où Aerunit s'intègre
En plus de l'intégration Linear et des Automations propres à Cursor, Aerunit ajoute quatre choses :
- Il rédige les stories. Vous décrivez le travail ; Aerunit lit chaque dépôt que la story touche et propose des tickets Linear avec périmètre, critères d'acceptation et non-objectifs — une story parente plus un sous-ticket par dépôt pour le travail multi-dépôts.
- Il répartit dans l'ordre de dépendance. Aerunit suit les relations blocks/blocked-by de Linear, donc quand une PR est mergée, les tickets qu'elle bloquait partent automatiquement vers Cursor Cloud Agents — pas de répartition manuelle.
- Il relit chaque PR. Quand un agent ouvre une pull request, Aerunit effectue une revue de code et renvoie les remarques à la même session d'agent pour correction — ainsi l'agent qui a écrit le code est celui qui le corrige.
- Il montre toute la flotte. Une liste de chaque session de Cloud Agent en cours, chacune liée à son ticket Linear — envoyez un message à plusieurs à la fois, archivez celles qui sont terminées.
Moteur : Cursor
Exécute chaque tâche dans sa propre VM cloud et ouvre la pull request.
Répartiteur : Aerunit
Rédige la story, l'envoie quand son bloqueur est mergé, relit la PR.
Questions fréquentes
Combien d'agents en arrière-plan Cursor puis-je faire tourner en même temps ?
Autant que vous voulez, en parallèle — ils tournent dans leurs propres VM et n'ont pas besoin que votre machine soit connectée. Deux limites pratiques demeurent : le coût, car les Cloud Agents sont facturés au tarif API du modèle choisi et chaque agent en parallèle s'ajoute à la facture ; et la revue, car chaque agent vous remet une pull request à vérifier. [3]
Cursor a déjà une intégration Linear et des Automations — pourquoi Aerunit ?
Cursor est le moteur : vous assignez un ticket Linear à @Cursor et un agent l'exécute, ou vous déclenchez des runs à partir d'événements avec Automations. Aerunit est le répartiteur au-dessus : il rédige les stories (sur plusieurs dépôts), suit les relations de blocage de Linear pour que la tranche suivante démarre dès que son bloqueur est mergé, relit automatiquement chaque PR d'agent et renvoie les remarques à l'agent, et affiche toutes les sessions en cours dans une seule liste, chacune liée à son ticket Linear. [5] [4]
Les agents en arrière-plan tournent-ils sur mon ordinateur ?
Non. Chaque Cloud Agent tourne sur une machine virtuelle dédiée dans le cloud avec votre dépôt, vos dépendances, vos secrets et un accès réseau — isolée et confinée (sandbox) par rapport à votre machine locale. Vous pouvez fermer votre ordinateur portable et vérifier le résultat plus tard. [1]
Comment savoir ce que l'agent a vraiment fait ?
Les agents joignent des captures d'écran, des vidéos et des références de logs à la pull request pour que vous puissiez valider le travail sans récupérer la branche. Vous pouvez aussi prendre le contrôle du bureau distant de l'agent pour essayer le logiciel vous-même. [2]
Un agent en arrière-plan peut-il travailler sur plusieurs dépôts ?
Oui. Les environnements multi-dépôts permettent à un seul agent d'inspecter tout l'espace de travail, de faire des changements coordonnés sur des dépôts frontend, backend, infrastructure ou bibliothèques partagées, et d'ouvrir une pull request dans chaque dépôt qu'il modifie. [3]