Automatisations
Les automatisations Cursor exécutent des agents cloud en arrière-plan, selon une planification ou en réponse à des événements provenant de GitHub, GitLab, Slack, de webhooks, de Linear, etc.
Les automatisations permettent d’automatiser des tâches telles que l’examen des commits récents d’une PR pour détecter des bugs, une revue approfondie pour détecter des vulnérabilités, le tri des bugs dans Slack et la synthèse planifiée des modifications apportées à votre base de code.
Premiers pas
Créez une automatisation dans la Fenêtre Agents, sur cursor.com/automations, avec la compétence /automate depuis une session d'agent locale ou à partir d'un modèle du Cursor Marketplace.
La compétence /automate vous permet de décrire le flux de travail souhaité en langage naturel. Cursor configure pour vous les déclencheurs, les instructions et les outils de l'automatisation.
Quelle que soit la méthode choisie :
- Choisissez un déclencheur, par exemple toutes les heures ou à l'ouverture d'une pull request.
- Rédigez un prompt contenant les instructions de l'automatisation.
- Choisissez les outils facultatifs que l'agent peut utiliser, tels que Send to Slack, Comment on Pull Request ou des outils MCP.
- Indiquez si l'automatisation nécessite un dépôt, plusieurs dépôts ou aucun dépôt.
- Enregistrez et activez l'automatisation.
La page Automatisations propose également trois agents gérés par Cursor :
- Bugbot examine les pull requests pour détecter les bugs et les problèmes de qualité du code.
- Les agents de sécurité examinent les pull requests et analysent les bases de code à la recherche de vulnérabilités.
- Routage et approbation des PR achemine les pull requests vers des reviewers et peut approuver les modifications à faible risque.
Facturation
Les automatisations créent des agents cloud et leur facturation dépend de l’usage des agents cloud. Consultez la tarification des agents cloud pour en savoir plus.
Les automatisations utilisent la fenêtre de contexte maximale prise en charge par chaque modèle, car elles s’exécutent en tant qu’agents cloud. Il n’est pas possible de modifier la fenêtre de contexte.
La facturation de l’usage dépend du périmètre d’autorisation de l’automatisation :
- Propriété de l’équipe : L’usage est facturé au pool d’usage de l’équipe. Les automatisations s’exécutent avec un compte de service partagé par l’équipe ; l’usage d’aucun utilisateur individuel n’est donc affecté.
- Privé : L’usage est facturé à l’utilisateur qui a créé l’automatisation.
- Visible à l’équipe : L’usage est facturé à l’utilisateur qui a créé l’automatisation, comme pour Privé.
Déclencheurs
Les déclencheurs déterminent quand une automatisation s’exécute. Une automatisation peut avoir plusieurs déclencheurs et s’exécute dès que l’un d’eux se déclenche.
Pour certains déclencheurs, comme Slack ou les planifications cron, Cursor n’utilise aucun dépôt par défaut. Si votre automatisation doit apporter des modifications de code, indiquez le ou les dépôts dans lesquels les agents doivent travailler. Pour les déclencheurs de gestion du code source, il est obligatoire de spécifier un ou plusieurs dépôts.
Déclencheurs planifiés
Les déclencheurs planifiés s’exécutent de manière récurrente. Choisissez parmi les options prédéfinies ou saisissez une expression cron pour un contrôle précis.
Les déclencheurs planifiés peuvent s’exécuter avec un retard, mais ne démarreront pas avant l’heure indiquée.
Déclencheurs de gestion du code source
Les déclencheurs de gestion du code source réagissent aux événements de pull request et de push de votre fournisseur Git connecté : GitHub, GitLab ou Bitbucket Cloud. Connectez l’automatisation à un dépôt ou à un environnement multi-repo.
Tous les fournisseurs connectés prennent en charge les principaux déclencheurs de pull request et de push :
- Brouillon ouvert - Lorsqu’une pull request en brouillon est créée.
- Pull request ouverte - Lorsqu’une PR non brouillon est créée ou qu’un brouillon est marqué comme prêt pour la revue.
- Pull request mise à jour - Lorsque de nouveaux commits sont poussés vers une PR existante.
- Pull request fusionnée - Lorsqu’une PR est fusionnée.
- Push vers une branche - Lorsque des commits sont poussés vers une branche spécifique en dehors d’une pull request.
- Commentaire ajouté - Lorsqu’une personne laisse un commentaire de premier niveau sur une pull request.
GitHub prend en charge le plus de déclencheurs. GitLab et Bitbucket prennent en charge les principaux déclencheurs ci-dessus, ainsi que quelques déclencheurs supplémentaires répertoriés dans les sections correspondantes ci-dessous.
Déclencheurs GitHub
GitHub est le fournisseur de référence et prend en charge tous les déclencheurs de gestion du code source. Outre les déclencheurs principaux, il propose également :
- Libellé de pull request modifié - Lorsqu’un libellé spécifique ou n’importe quel libellé est ajouté à une pull request ou supprimé.
- Libellé d’issue modifié - Lorsqu’un libellé est ajouté à une issue autre qu’une PR ou supprimé.
- CI terminée - Lorsqu’une vérification GitHub se termine sur une pull request ou une branche.
- Commentaire d’issue - Lorsqu’un commentaire est ajouté à une issue autre qu’une PR.
- Commentaire de revue de PR - Lorsqu’un commentaire en ligne est ajouté à un diff de pull request.
- Revue de PR soumise - Lorsqu’une revue est soumise avec le statut approuvée, modifications demandées ou commentée.
- Fil de revue mis à jour - Lorsqu’un fil de revue sur une pull request est marqué comme résolu ou non résolu.
- Exécution de flux de travail terminée - Lorsqu’une exécution de flux de travail GitHub Actions se termine sur une pull request ou une branche.
Le Cursor Marketplace propose des modèles pour trier les échecs de GitHub Actions et corriger les commentaires de revue de pull request.
Déclencheurs GitLab
En plus des déclencheurs principaux, GitLab ajoute :
- Libellé de pull request modifié - Lorsqu'un libellé est ajouté à une merge request ou en est supprimé.
- Pull request approuvée - Lorsqu'une merge request est approuvée.
Déclencheurs Bitbucket
La prise en charge de Bitbucket concerne uniquement Bitbucket Cloud (bitbucket.org). Bitbucket Server et Data Center ne sont pas pris en charge. En plus des déclencheurs principaux, Bitbucket ajoute :
- Pull request approuvée - Lorsqu'une pull request est approuvée.
Bitbucket Cloud ne propose pas de déclencheur basé sur les étiquettes de pull request ni sur les commentaires de revue en ligne.
Les déclencheurs de pull request ne s'exécutent pas sur les PR ouvertes depuis des forks. Ces exécutions échouent avec l'erreur « Fork pull requests not supported », car la branche n'existe que dans le fork et qu'il n'est pas sûr d'exécuter du code externe avec les autorisations du dépôt. Les déclencheurs Pull request fusionnée font exception : ils s'exécutent tout de même, car ils partent du commit de fusion. Pour contourner ce problème, poussez la branche vers le dépôt lui-même et ouvrez la PR depuis celui-ci.
Déclencheurs Slack
Les déclencheurs Slack réagissent aux événements de l'intégration Slack de Cursor.
Pour l’instant, les déclencheurs Slack ne peuvent voir que les salons Slack publics.
- Nouveau message dans un salon - Lorsqu’un message est envoyé dans un salon Slack connecté. Sans filtre de messages, le déclencheur ne s’active que pour les messages de premier niveau du salon. Ajoutez un filtre par mot-clé ou expression régulière pour également lancer des exécutions à partir des réponses dans les fils de discussion.
- Réaction par emoji - Lorsqu’une personne réagit à un message Slack avec un emoji spécifique.
- Salon créé - Lorsqu’un nouveau salon Slack public est créé dans votre espace de travail.
Déclencheurs de webhooks
Les déclencheurs de webhooks créent un endpoint HTTP privé pour votre automatisation. Envoyez une requête POST à cet endpoint pour lancer une exécution. Vous pouvez utiliser des webhooks pour connecter des automatisations à des systèmes internes, des pipelines CI, des outils de surveillance, etc.
Pour obtenir l’URL du webhook, vous devez d’abord enregistrer l’automatisation. Cela génère une URL de webhook à appeler ainsi qu’une clé API pour l’authentification.
Déclencheurs Linear
Les déclencheurs Linear réagissent aux événements de l'intégration Cursor Linear.
- Issue créée - Lorsqu’une nouvelle issue est créée.
- Statut modifié - Lorsque le statut d’une issue est modifié.
- Fin du cycle - Lorsqu’un cycle Linear se termine.
Déclencheurs Sentry
Les déclencheurs Sentry s'exécutent lorsque des événements d'erreur ou d'issue surviennent dans votre projet Sentry. Utilisez-les pour analyser automatiquement les erreurs, identifier les causes racines et proposer des correctifs. Consultez le modèle Marketplace Investigate Sentry issues pour un exemple prêt à l'emploi.
- Issue créée - Lorsqu'une nouvelle issue est créée dans Sentry.
- Issue mise à jour - Lorsqu'une issue existante est modifiée, par exemple lors d'une mise à jour de son statut ou de son affectation.
- Tout événement lié à une issue - Correspond à tous les types d'événements liés à une issue.
Déclencheurs PagerDuty
Les déclencheurs PagerDuty s’exécutent en réponse à des événements liés aux incidents et permettent de trier automatiquement les incidents, voire de les résoudre.
- Incident déclenché - Lorsqu’un nouvel incident est créé.
- Incident pris en compte - Lorsqu’un incident est pris en compte.
- Incident résolu - Lorsqu’un incident est résolu.
- Tout événement d’incident - Correspond à tous les types d’événements liés aux incidents.
Outils
Cursor automatisation peut activer des outils afin d’offrir des fonctionnalités avancées liées à GitHub, Slack, à la mémoire, à MCP, etc. Les automatisations incluent également le même ensemble d’outils de base que les autres agents cloud. Voir fonctionnalités de l’agent cloud pour plus de détails.
Création de pull requests
Les automatisations associées à un dépôt peuvent ouvrir des pull requests après avoir apporté les modifications de code demandées dans le prompt d’automatisation. Cet outil est activé par défaut pour chaque automatisation.
La pull request est ouverte dans les dépôts spécifiés pour le déclencheur de gestion du code source. Pour les autres déclencheurs, les dépôts spécifiés dans l’environnement sont utilisés.
Commenter une pull request
Publie des commentaires sur une pull request cible. Prend en charge les commentaires de revue généraux et les commentaires en ligne sur le code.
Si vous activez les approbations, l’Agent peut également approuver, demander des modifications et annuler des revues. Sinon, il peut uniquement publier des commentaires.
Demander une relecture
Demande une relecture pour une pull request cible. L’agent peut utiliser git, la mémoire et d’autres outils pour identifier les experts du domaine.
Envoyer vers Slack
Envoie des messages dans un salon Slack. Vous pouvez cibler un salon spécifique ou laisser l’agent choisir dynamiquement n’importe quel salon.
Lorsque vous autorisez tous les salons, Cursor accorde également à l’agent l’accès en lecture nécessaire pour découvrir les salons publics disponibles.
Notez que l’agent dispose d’un accès en lecture aux salons publics dans lesquels il peut envoyer des messages.
Lire les salons Slack
Donne à l’agent un accès en lecture seule pour répertorier et lire les messages des salons Slack publics.
À utiliser lorsque l’agent a besoin de davantage de contexte avant de répondre ou d’ouvrir une pull request.
Serveur MCP
Connecte un serveur MCP (Model Context Protocol) afin que l’agent puisse utiliser des outils externes et des sources de données.
La connexion d’un serveur MCP donne à l’agent accès à tous les outils exposés par ce serveur. Ne connectez que des serveurs de confiance, avec les autorisations requises par votre automatisation.
Mémoires
Les mémoires permettent à l’agent de lire et d’écrire des notes persistantes d’une exécution à l’autre pour une même automatisation. Utilisez-les pour créer des agents capables de se souvenir et de s’améliorer au fil du temps. Chaque mémoire est stockée sous la forme d’une entrée nommée (MEMORIES.md par défaut), distincte du système de fichiers de travail de l’agent.
Les mémoires sont activées par défaut, mais peuvent être désactivées. Vous pouvez les consulter et les modifier depuis l’interface utilisateur de configuration des outils.
Les agents peuvent supprimer les fichiers de mémoire obsolètes lors des exécutions d’automatisation. Vous pouvez également supprimer des fichiers de mémoire depuis l’interface utilisateur de configuration des outils.
Les mémoires persistent d’une exécution à l’autre et doivent être utilisées avec prudence si votre automatisation traite des entrées non fiables. Des entrées peuvent générer des mémoires trompeuses ou malveillantes, susceptibles d’affecter involontairement de futures exécutions d’automatisation.
Utilisation de l’ordinateur
L’utilisation de l’ordinateur permet aux agents cloud lancés par des automatisations d’utiliser un ordinateur comme le ferait un développeur. Les automatisations peuvent ainsi piloter un navigateur, générer des captures d’écran ou des enregistrements, ou utiliser vos services internes. Cette fonctionnalité est incluse par défaut dans chaque automatisation.
Pour que l’utilisation de l’ordinateur soit efficace, assurez-vous d’avoir configuré un environnement de développement pour votre automatisation. Vous pouvez ensuite demander une démo dans les instructions de votre automatisation lorsque vous souhaitez que l’agent montre son travail. Par exemple, demandez à l’agent d’inclure un court enregistrement d’écran après avoir modifié un parcours utilisateur.
Paramètres d’automatisation
Modèle
Vous pouvez choisir le modèle utilisé par l’agent cloud pour votre automatisation.
Dépôts
Choisissez si l’automatisation ne nécessite aucun dépôt, un seul dépôt ou un environnement multi-dépôts.
Le paramètre de dépôt définit le contexte de base de code de chaque exécution :
- Aucun dépôt : l’Agent ne clone pas de code. Utilisez cette option pour les flux de travail qui nécessitent uniquement Slack, MCP, des webhooks, Linear ou PagerDuty. Il ne peut ni modifier le code ni ouvrir de pull requests.
- Dépôt unique : l’Agent travaille dans un dépôt et une branche. Utilisez cette option lorsque l’automatisation doit lire, passer en revue ou modifier du code dans une seule base de code.
- Environnement multi-dépôts : l’Agent travaille dans les dépôts d’un environnement. Utilisez cette option lorsque la tâche s’étend à plusieurs bases de code.
Pour certains déclencheurs, comme Slack ou les planifications cron, Cursor n’utilise aucun dépôt par défaut. Si votre automatisation doit apporter des modifications de code, indiquez dans quel dépôt ou quels dépôts les Agents doivent travailler.
Pour les déclencheurs de gestion du code source, vous devez indiquer un ou plusieurs dépôts.
Automatisations sur un seul dépôt
Par défaut, une automatisation s’exécute sur un dépôt et une branche. C’est le bon choix lorsque l’agent doit lire, passer en revue ou modifier du code dans une seule base de code.
Les déclencheurs de gestion du code source déterminent le dépôt à partir de la pull request. Pour les autres déclencheurs, sélectionnez le dépôt et la branche dans les paramètres de l’automatisation.
Automatisations multi-repo
Utilisez un environnement multi-repo lorsqu'une automatisation doit intervenir sur plusieurs dépôts. Sélectionnez plusieurs dépôts lors de la configuration de l'environnement, ou choisissez un environnement existant dans votre Cloud Agents dashboard.
Autorisations
Contrôlez qui peut consulter et gérer l’automatisation. Le périmètre d’autorisation détermine également comment l’usage est facturé.
- privé : Vous seul pouvez gérer l’automatisation. Les administrateurs de l’équipe peuvent la consulter et la désactiver.
- visible à l’équipe : Vous seul pouvez gérer l’automatisation. Les membres de l’équipe peuvent la consulter, et les administrateurs de l’équipe peuvent la désactiver. Elle s’exécute toujours avec votre authentification.
- propriété de l’équipe : Les membres de l’équipe peuvent consulter l’automatisation. Seuls les administrateurs de l’équipe peuvent la gérer. Elle s’exécute avec le compte de service partagé de l’équipe pour les automatisations.
Faire passer une automatisation de privé ou visible à l’équipe à propriété de l’équipe modifie l’identité sous laquelle elle s’exécute. Elle n’utilise plus votre authentification et utilise désormais le compte de service partagé de l’équipe pour les automatisations. Si l’automatisation utilise des déclencheurs webhook, régénérez sa clé API webhook après le changement de périmètre. Si elle utilise des MCP ou d’autres intégrations reposant sur des identifiants OAuth personnels, assurez-vous qu’ils sont plutôt configurés pour le compte de service de l’équipe. Seuls les administrateurs de l’équipe peuvent faire passer une automatisation à propriété de l’équipe.
Identité
Lorsqu’une automatisation interagit avec des services externes, elle utilise les identités suivantes :
- Les commentaires GitHub, les approbations de revue et les demandes de relecteurs sont effectués sous l’identité
cursor. - Les automatisations associées à une équipe ouvrent des pull requests sous l’identité
cursor. - Les automatisations privées ouvrent des pull requests avec votre compte GitHub.
- Les messages Slack sont envoyés par le bot Cursor.
Rédiger des prompts
Les prompts définissent ce que l’agent doit faire. Rédigez-les comme vous rédigeriez des instructions pour une exécution d’agent cloud.
Conseils :
- Indiquez précisément ce que l’agent doit vérifier, modifier ou produire.
- Faites référence aux actions que vous avez activées : vous pouvez mentionner des outils avec @ ou citer leur nom de manière informelle.
- Incluez des règles de décision pour préciser quoi faire selon les cas.
- Définissez un niveau de qualité à atteindre pour que l’agent ouvre une pull request, ajoute un commentaire ou ne fasse rien.
- Décrivez le format de sortie souhaité.