Cursor Automations : guide pratique des agents de code toujours actifs

Le vrai goulot d’étranglement en développement logiciel n’est plus l’écriture du code : presque chaque développeur, dans des équipes de toute taille, dispose désormais d’au moins un agent qui l’aide à livrer. Les agents de code s’intègrent au quotidien dans les workflows, et l’implémentation n’est plus la partie la plus lente du système.

Cursor Automations a été conçu pour combler cet écart. Plutôt que de solliciter sans cesse un agent, vous définissez quand il doit agir. Un déclencheur s’active, des instructions guident l’action, et il s’exécute de manière autonome. Une pull request s’ouvre : elle est relue. Un rapport de bug arrive dans Slack : il est traité. Une planification s’exécute : un rapport est généré.

Dans ce tutoriel, je vous montre comment configurer de bout en bout des automations Cursor. Vous allez créer deux automations : une relecture de PR et un suivi planifié de la couverture de tests. En chemin, j’expliquerai comment structurer les instructions et connecter des outils et MCP afin que les automations se comportent comme prévu.

Une remarque avant de commencer : Automations est encore en développement, et le tableau de bord sur cursor.com/automations évolue. Si un libellé de menu ou un bouton a changé entre-temps, la logique sous-jacente reste la même.

Qu’est-ce que Cursor Automations ?

Cursor automations est un système pour exécuter automatiquement les agents cloud de Cursor, déclenchés par des événements dans vos outils de développement ou selon une planification que vous définissez.

En mode Agent de Cursor, comme expliqué dans notre cours Software Development with Cursor, vous démarrez chaque session en ouvrant un chat et en saisissant une consigne, et l’agent tourne sur votre machine locale tant que vous le suivez.

Avec les automations, le signal de départ provient d’ailleurs dans votre stack, et l’agent travaille dans un bac à sable cloud sans que vous ayez à le surveiller.

Les automations comprennent des événements de déclenchement résumés dans le tableau ci-dessous, mais vous pouvez aussi créer des déclencheurs personnalisés via des webhooks. Une automation peut avoir plusieurs déclencheurs et s’exécute dès que l’un d’eux se produit.

Chacun de ces types de déclencheurs remplace un moment de votre journée où vous auriez dû remarquer quelque chose, basculer en mode Agent de Cursor et demander de l’aide.

Le déclencheur sur les pull requests est probablement celui que vous créerez en premier. Voici à quoi ressemble le cycle de vie d’une PR avant et après l’ajout d’une automation qui surveille votre dépôt.

Ce qui change dans cette deuxième colonne, ce n’est pas la vitesse de chaque étape, mais le fait que votre attention n’est plus le facteur limitant l’ensemble du processus.

Comment Cursor Automations fonctionne sous le capot

Chaque automation suit la même chaîne de traitement. Quand le déclencheur que vous avez défini s’active, Cursor lance un nouveau bac à sable cloud, clone votre dépôt, et démarre un agent qui suit vos instructions avec les outils, connexions MCP et modèle configurés. Ce dépôt n’a pas besoin d’être sur GitHub : les dépôts hébergés sur Cursor Origin, la forge Git de Cursor, fonctionnent aussi avec les agents cloud et les automations.

Avant de terminer, l’agent vérifie sa sortie, puis publie le résultat là où vous l’avez configuré : commentaire de PR, message Slack, ticket Linear, ou ouverture d’une nouvelle pull request.

Deux propriétés structurent chaque automation :

• Le bac à sable s’exécute entièrement dans le cloud de Cursor, pas sur votre ordinateur. Il continue même si votre machine est éteinte.
• Chaque exécution est isolée. Plusieurs automations peuvent tourner en parallèle sans interéagir. Cursor indique également exécuter des centaines d’automations par heure en interne.

Il existe aussi un outil de mémoire, comme montré dans l’aperçu ci-dessous, qui permet à votre automation de conserver un état entre deux exécutions : cela devient important quand nous construirons le suivi planifié de la couverture.

Nous y reviendrons lors de la création du suivi de couverture planifié.

Cursor Automations vs mode Agent

Si vous utilisez déjà Cursor régulièrement, la question clé est de savoir quand utiliser les automations au lieu du mode Agent. J’éviterais les automations pour des tâches uniques. Elles sont faites pour le travail répétitif ou déclenché par des événements externes.

Une comparaison aide quand le choix n’est pas évident :

Je le formule ainsi : si une tâche commence par « chaque fois que » ou « dès qu’», elle relève des Automations.

Par exemple : « Chaque fois qu’une PR est ouverte, ou dès qu’un rapport de bug arrive dans #support, créez un ticket Linear. » Le déclencheur est récurrent et prévisible.

Si cela commence par « là, tout de suite, j’ai besoin de refactorer ce module », c’est du mode Agent. C’est vous qui décidez de ce « tout de suite ».

Si vous voulez explorer Cursor avant de plonger dans les automations, notre guide complet Cursor 2.0 vous fait découvrir l’interface Agents, Composer et le workflow multi-agent avec un projet Python entier.

Accéder au tableau de bord Automations

Le tableau de bord des automations Cursor se trouve sur cursor.com/automations. Connectez-vous avec votre compte Cursor : vous arrivez sur le tableau de bord principal, comme ci-dessous :

Décomposons ce que nous voyons sur le tableau de bord.

Tuiles récapitulatives / indicateurs d’état en haut

Ces tuiles offrent un instantané de santé de tout ce qui a tourné. Elles incluent :

• Total des automations (combien vous en avez configuré)
• Réussites (exécutions terminées, avec un taux de succès)
• Échecs (exécutions en erreur)
• Historique des exécutions (au clic, vue du volume d’exécution dans le temps)

Le champ de saisie d’instructions

Ce champ est la façon la plus rapide de créer une nouvelle automation sans ouvrir tout le formulaire. Décrivez la tâche, et Cursor génère la structure de l’automation.

Si vous débutez, je vous recommande de commencer ici. Définissez ce que vous voulez automatiser, puis écrivez un jeu d’instructions structurées que l’agent suivra à chaque déclenchement.

Une fois l’icône flèche cliquée, Cursor utilise ces instructions pour générer l’automation, en préremplissant le nom, les déclencheurs et les outils requis.

Ne traitez pas ces instructions comme une simple consigne, mais comme un cahier des charges exécuté à chaque fois. Nous y reviendrons lors de la création de votre première automation.

Le basculeur « Mes / Équipe » et le bouton + nouvelle automation

Le basculeur filtre entre vos automations et celles de l’équipe.

Le + New ouvre une page de configuration pour créer une nouvelle automation :

Le bouton + New Automation est l’alternative plus détaillée au champ inline si vous souhaitez configurer manuellement, de zéro, le déclencheur, les instructions et les connexions d’outils.

Votre liste d’automations existantes

Le tableau récapitule toutes les automations créées, y compris les outils utilisés et l’historique des exécutions.

Cliquer sur l’une d’elles ouvre sa page de réglages et son historique :

Section de modèles suggérés

Sous la liste de vos automations, un quadrillage de cartes de modèles. Ces modèles proposent des automations préconçues que vous pouvez adapter au lieu de repartir de zéro.

Les modèles d’automation Cursor sont le moyen le plus rapide de mettre en route une automation dès le premier jour. Pour une première automation, vérifiez s’il existe un modèle correspondant à votre besoin et partez de là.

Les modèles vous donnent une idée de bonnes instructions et des connexions d’outils ou MCP à prévoir.

Compte et coûts

Les automations Cursor tournent sur l’infrastructure cloud de Cursor et nécessitent l’accès cloud agent, inclus dans les offres payantes. Chaque exécution consomme des crédits selon le modèle utilisé et le temps d’exécution.

Les automations gèrent trois niveaux de visibilité, conformément au modèle de permissions :

• Privé : vous seul la voyez, et la facturation est sur votre compte.
• Visible par l’équipe : les autres peuvent voir vos automations et l’historique, mais la facturation reste chez vous.
• Propriété équipe : facturée sur le pool partagé de l’équipe et gérée par les administrateurs.

Choisir le bon niveau est important : il détermine quels crédits sont consommés à chaque run. Gardez vos expérimentations en privé tant que vous n’avez pas confiance dans la sortie. Quand l’automation s’intègre au workflow d’équipe, basculez-la au niveau équipe.

Le principal risque est de laisser une automation s’exécuter trop largement, trop tôt. Si elle se déclenche sur chaque push d’un dépôt très actif, l’usage peut grimper vite sans que vous le voyiez. Commencez restreint, laissez tourner quelques jours, analysez la fréquence de déclenchement, puis décidez d’élargir ou de passer à l’échelle.

Créer votre première automation Cursor : relecture de code automatisée sur PR

La relecture de code sur PR est idéale pour démarrer : la boucle de feedback est courte et les conséquences d’un échec sont faibles. Si l’agent publie un commentaire utile, nous le voyons tout de suite dans la PR. S’il publie à côté, on l’ignore et rien n’est livré.

Voici les cinq étapes pour construire votre première automation :

1. Connexion de votre dépôt GitHub
2. Configuration des déclencheurs GitHub
3. Rédaction des instructions de l’agent (structure claire et à éviter)
4. Ajout de l’outil de commentaire sur pull request GitHub
5. Déploiement de l’automation

Étape 1 : connecter votre dépôt GitHub

Avant de relire une PR, l’agent a besoin d’accéder au dépôt. Cursor y accède via une intégration native GitHub App. Sans cette connexion, l’agent ne peut pas voir votre code, lire les diffs de PR ni publier de feedback : rien ne fonctionne vraiment.

Si ce n’est pas encore fait :

1. Installez l’application Cursor pour GitHub sur votre compte ou organisation GitHub et accordez-lui l’accès aux dépôts à surveiller.
2. Connectez votre compte GitHub dans le dashboard, onglet Integrations.

Une fois la connexion active, vos dépôts seront disponibles lors de la configuration du déclencheur.

Étape 2 : configurer vos déclencheurs

Depuis le tableau de bord des automations :

1. Cliquez sur + New Automation pour créer une automation.
2. Nommez l’automation. Par exemple : PR Code Review – Open & Push – Comment Only
3. Dans la section déclencheurs, cliquez sur Add trigger et sélectionnez GitHub. Choisissez PR opened et PR pushed comme événements.
4. Sélectionnez le dépôt cible.

Si vous avez sauté l’étape 1 ou si c’est votre première connexion GitHub pour les automations Cursor, une authentification vous sera demandée.

Dans l’aperçu ci-dessous, je montre comment le configurer et choisir le dépôt cible une fois l’autorisation terminée :

Remarque : nous pouvons regrouper plusieurs événements de déclenchement dans une même automation lorsque les instructions ne changent pas selon l’événement. Mais si la profondeur ou l’objectif de la relecture varient, préférez des automations séparées.

L’automation sait désormais quand s’exécuter. L’étape suivante est de lui dire quoi faire.

Étape 3 : rédiger des instructions efficaces

Les instructions sont le levier numéro un pour obtenir une sortie utile. L’agent y apprend ce à quoi ressemble le « bon ». Des instructions vagues donnent des résultats incohérents.

Avant d’écrire, comprenons ce que nous définissons. Ce n’est pas une consigne ponctuelle : c’est un comportement que l’agent appliquera à chaque déclenchement. La qualité de l’automation dépend de la précision de ce comportement.

Voici la structure recommandée :

• Définir le rôle : cela fixe la perspective et le ton. Par exemple : « Vous êtes relecteur sécurité pour les pull requests. »
• Définir l’objectif : décrire le succès. Par exemple : « Détecter et expliquer clairement les vraies vulnérabilités. »
• Définir le périmètre : préciser le focus. Par exemple : « Ne relire que le code ajouté ou modifié. »
• Décrire le workflow : une méthode claire d’approche. Par exemple : « Inspecter les changements, tracer les entrées, vérifier les protections. »
• Fixer des exclusions : dire explicitement quoi ignorer, pour réduire le bruit.
• Définir le comportement et la sortie : comment agir et à quoi doit ressembler le résultat.
• Poser les limites : ce qui ne doit jamais être fait.

Rédigez les instructions comme un runbook : spécifiques, ordonnées, avec des critères d’acceptation clairs et des limites explicites.

Exemple d’instruction efficace

Voici l’instruction que j’ai utilisée pour cette automation de relecture de PR. Vous pouvez la copier dans votre zone d’instructions, puis l’adapter à votre contexte :

You are a code reviewer for pull requests triggered on PR open and push. Focus on identifying real issues that could introduce bugs, security vulnerabilities, or maintainability problems if merged. Review only added or modified code, and use surrounding context only when required to validate impact.

Check for:
- Logic errors such as incorrect conditions, edge cases, null handling, or wrong return values
- Security issues including injection, XSS, auth flaws, unsafe deserialization, or hardcoded secrets
- Contract changes such as modified APIs, response shapes, or schemas without corresponding updates
- Missing error handling or tests introduced by the change

Ignore style, formatting, naming preferences, and any pre-existing issues not introduced by this PR. Report only concrete findings with evidence from the diff, and post inline comments directly on changed lines. If no issues are found, respond: “Automated review complete: no issues found in this diff.” Do not approve, merge, push, or open PRs.Propulsé par

Voici l’instruction dans la zone de saisie :

Cette consigne est simplifiée, mais elle suit une structure claire et spécifique.

Exemple d’instruction à éviter

Évitez les instructions vagues du type :

Review this PR and give feedback on any issues you notice.Propulsé par

Sans structure, contraintes et priorités, l’agent doit deviner ce que « issues » signifie, et produit un retour générique plutôt qu’un résultat fiable.

Étape 4 : ajouter des outils

Ouvrez le panneau Outils dans l’éditeur d’automation. Pour cette automation, allez dans la section GitHub et sélectionnez l’outil Comment on Pull Request. Désactivez l’approbation de PR, comme dans l’aperçu ci-dessous, afin que l’automation puisse commenter, mais pas approuver.

L’outil Comment on Pull Request permet à l’agent de publier ses constats sur la PR. Il ne requiert pas de connexion séparée : il s’appuie sur la même application Cursor pour GitHub autorisée à l’Étape 1.

Si nous voulons envoyer la sortie vers d’autres services (comme Slack), nous sélectionnons l’outil correspondant ou ajoutons une connexion MCP. Pour cette automation, le commentaire PR suffit.

Étape 5 : déploiement et suivi de la première exécution

Une fois déclencheurs, instructions et outils en place, cliquez sur Create pour enregistrer l’automation : sa page de réglages s’ouvre, comme ci-dessous :

Puis, déclenchez un run et observez la sortie de l’agent.

Ouvrez une pull request en brouillon dans votre dépôt connecté. Cela déclenche « PR opened » et une nouvelle entrée doit apparaître dans l’Historique des exécutions en quelques secondes, comme ci-dessous :

Ouvrez ce run et vérifiez trois points :

• Temps d’exécution : durée du run, variable selon la taille du diff, le modèle et la complexité des instructions.
• Appels d’outils : quels fichiers et outils ? Si l’agent lit des fichiers hors sujet, revoyez vos instructions.
• Sortie : ce qui a été publié sur GitHub. Comparez à vos instructions.

Ci-dessous, l’aperçu du run de mon automation. Elle a duré six minutes, a effectué des actions et a publié la relecture via l’outil PostReviewCommentOnPr :

Voici un exemple de commentaire publié par l’agent sur ma PR :

Il arrive que la sortie soit à côté : le problème vient généralement des instructions. Ajustez la partie concernée, poussez un nouveau commit pour relancer, puis révisez le résultat.

Pour ces premiers runs, restons simples pour limiter les risques. Ici, on restreint aux commentaires uniquement, ce qui permet de valider le comportement en sécurité. Une fois la sortie stable, mettez-la en usage réel, puis connectez d’autres outils au-delà de GitHub pour élargir le champ d’action.

Connecter plus d’outils avec MCP

L’automation de relecture PR que nous venons de créer tourne sur GitHub : elle lit le diff et publie des commentaires via l’outil GitHub Comment on Pull Request. Mais si nous voulons que l’agent aille au-delà de la relecture de code, il faut connecter d’autres outils. C’est à cela que sert le Model Context Protocol (MCP).

MCP est une interface standard qui permet aux agents d’utiliser des outils externes sans intégrations sur mesure. Sans MCP, chaque outil demanderait une configuration et une maintenance propres.

Avec MCP, une fois un outil pris en charge connecté dans le panneau Outils, l’agent peut l’utiliser via la même interface.

MCP permet à une même automation d’en faire plus et d’agir dans d’autres outils. Votre automation de relecture commente déjà sur GitHub. Ajoutez Slack : elle peut publier des mises à jour dans un canal. Ajoutez Linear : elle peut créer des tickets. Ajoutez Datadog : elle peut récupérer des logs. Chaque connexion étend ses capacités sans changer sa logique centrale.

Les automations Cursor incluent un catalogue intégré d’intégrations MCP comme Slack, Linear, ClickUp, Datadog, Notion, et plus encore. Comme MCP est un standard ouvert, nous pouvons connecter tout outil compatible de la même manière.

Vous trouverez MCP dans Tools -> MCP server sur la page des réglages de l’automation. Cliquez sur + New Connection pour parcourir, installer et connecter l’outil voulu.

Voici un aperçu de l’ajout :

Dans la section suivante, je vous guide pour ajouter une connexion Slack MCP à l’automation de relecture PR.

Ajouter une connexion Slack MCP

GitHub permet à l’automation de lire et commenter le code. Slack permet de parler à l’équipe.

Depuis le panneau Outils, cliquez sur Add Tool or MCP, sélectionnez MCP Server, puis +New Connection. Dans le panneau, cherchez Slack et choisissez le serveur MCP Slack.

Slack est souvent déjà installé ; sinon, installez-le et suivez le flux OAuth pour autoriser votre workspace. Une fois connecté, il apparaît dans vos outils, comme dans l’aperçu ci-dessous :

Nous ne sélectionnons pas de canal cible lors de la connexion. MCP donne à l’agent un accès au niveau workspace à tous les canaux publics. Nous contrôlons où il publie en nommant le canal dans les instructions, par exemple : « Envoyez un message Slack dans #pr-alerts si une anomalie critique est trouvée. »

Remarque : Slack MCP ne fonctionne qu’avec des canaux publics, et le canal cible doit avoir le bot Cursor invité avant la publication. Après l’OAuth, un bot Cursor doit apparaître dans votre workspace : allez dans le canal et lancez /invite @Cursor pour l’ajouter.

Si vous ne voyez pas le bot @Cursor, l’autorisation a peut-être échoué. Allez sur le dashboard -> integrations, cliquez sur Manage à côté de Slack et relancez l’OAuth.

Pour aller plus loin sur MCP, notre tutoriel FastMCP 2.0 explique comment construire un serveur MCP personnalisé et l’intégrer à Cursor.

Combiner déclencheurs et outils

Avec la connexion Slack MCP, nous pouvons étendre l’automation de relecture PR. Nous gardons les mêmes déclencheurs PR GitHub et l’outil de commentaire sur PR. Mais l’agent peut aussi publier les points critiques sur #pr-alerts via Slack MCP.

Ajoutez ce bloc à la fin des instructions rédigées à l’étape 3 :

Additionally:  
If you find any issue at severity high or critical, send a Slack message to #pr-alerts containing: the PR title, the author, a one-sentence description of the most severe finding, the severity label, and a link to the PR. If no high or critical issues are found, do not post to Slack at all.Propulsé par

Cette dernière phrase est importante. Sans elle, #pr-alerts se remplit d’« RAS » et perd son intérêt. Savoir quand ne pas agir est aussi important que savoir quand agir.

Voici les sorties d’un test PR sur mon dépôt.

Un commentaire publié par l’agent à l’ouverture de la PR dans GitHub (via l’outil de commentaire PR) :

La notification Slack envoyée par l’agent dans mon canal #pr-alerts pour le même run via la connexion Slack MCP :

Vous disposez désormais d’une automation qui relit chaque PR, commente sur GitHub et remonte les problèmes critiques sur Slack. C’est le schéma de base.

Dans la section suivante, nous bâtirons une seconde automation avec le même enchaînement : déclencheur, instructions et outils nécessaires à la production de la sortie.

Construire une seconde automation : suivi planifié de la couverture de tests

L’automation de relecture PR réagit aux événements GitHub. Les automations planifiées fonctionnent différemment : on définit quand l’agent doit s’exécuter, et il le fait à cette heure, indépendamment de l’activité du dépôt.

L’automation que nous construisons ici tourne chaque jour à 9 h, analyse le code fusionné sur la branche main durant les dernières 24 h, identifie les zones à couverture de tests insuffisante et publie un résumé dans #repo-coverage sur Slack.

Configurer un déclencheur cron et un outil

Depuis le tableau de bord :

• Cliquez sur + New pour créer une nouvelle automation.
• Nommez-la Daily Coverage Check – Main Branch.

Configurer le déclencheur

• Sous Triggers, sélectionnez Scheduled.
• Choisissez Every... > Day et réglez l’heure sur 9:00 AM.
• Pour un format différent (jours ouvrés, etc.), utilisez Custom (cron)
• Les déclencheurs planifiés n’infèrent pas le dépôt : sélectionnez le dépôt et la branche (main).

Ajouter l’outil Send to Slack

Voici l’outil Send to Slack disponible dans les réglages. Il diffère de Slack MCP utilisé plus haut : on l’emploie pour envoyer des messages vers un canal spécifique, tandis que Slack MCP fournit un accès workspace et laisse l’agent publier dans n’importe quel canal défini dans les instructions.

Pour ajouter Send to Slack, sélectionnez-le dans la section des outils et précisez le canal cible pour la sortie de l’automation. Voici à quoi cela ressemble :

Rédiger les instructions d’une tâche planifiée

Dans l’automation de relecture PR, l’agent réagit à une PR et publie un feedback. Dans une automation planifiée, il n’y a pas d’entrée en provenance de l’événement : l’agent démarre seul. Il faut donc être clair sur le point de départ, les contrôles à effectuer et la sortie à publier.

L’outil de mémoire est crucial ici. La comparaison de couverture ne fonctionne que si l’agent connaît les chiffres de la veille. Il faut indiquer quelle clé lire, quoi comparer et quoi stocker à la fin. Sans cela, les résultats varient entre runs.

Voici l’ensemble d’instructions utilisé :

You are a daily test coverage monitor for this repository. Run every day at 9 AM on the main branch.
Identify PRs merged to main in the last 24 hours.For modified files, check if changed code paths have test coverage.Run tests with coverage:  pytest --cov=src --cov-report=json.Parse the report and record the overall coverage and per-file coverage for modified files.Read yesterday's coverage from memory (daily_coverage_latest: If none exists, post a green status and skip comparison.Compare coverage: If it drops by >1%, post a warning to #repo-coverage Slack Channel with today's value, yesterday's value, delta, and affected files. Otherwise, post a green status with today’s value and delta.Save today’s coverage to memory (daily_coverage_latest).Propulsé par

Ci-dessous, les sorties de mon automation planifiée à 9 h.

Voici la vue d’ensemble : dans mon cas, la couverture est restée au-dessus du seuil, donc un statut vert a été publié dans Slack :

Voici le message Slack. C’est le premier run de couverture, donc je n’attendais pas grand-chose. Vous voyez aussi que le run a été sauvegardé en mémoire comme base pour la prochaine comparaison :

Deux points ressortent dans ces instructions.

D’abord, elles définissent à la fois le chemin d’alerte et le chemin « vert ». Ce dernier est indispensable : si l’on décrit seulement quoi faire en cas de problème, l’automation reste silencieuse quand tout va bien ; dans un canal de monitoring, ce silence ressemble à un échec. Le statut vert confirme le bon déroulement.

Ensuite, la lecture et l’écriture en mémoire sont explicites. L’agent dispose d’un outil de mémoire, mais il ne l’utilisera pas de manière fiable pour des comparaisons sans instruction claire. Il faut préciser quelle clé lire, quoi comparer et quoi enregistrer.

Dans l’image ci-dessous, vous voyez que l’agent a bien sauvegardé mon automation :

Dans la section suivante, je couvre les pièges courants et les bonnes pratiques pour tirer le meilleur parti de vos automations.

Cursor Automations : pièges courants et bonnes pratiques

La plupart des problèmes proviennent d’un petit nombre d’erreurs prévisibles. Faciles à éviter une fois connues, coûteuses à déboguer sinon.

Erreurs fréquentes à éviter

• Instructions vagues : c’est un classique. « Relire le code », « vérifier les problèmes », « résumer les changements » forcent l’agent à deviner, d’où une sortie incohérente. Si une phrase a un verbe sans objet ni condition clairs, réécrivez-la avant d’aller en production.
• Périmètre trop large : n’agglomérez pas vérifs sécurité, style, perf et couverture dans une seule automation : débogage plus difficile. Des automations ciblées sont plus lisibles.
• Zapper la phase de calibration : n’activez pas trop tôt l’approbation ou la fusion auto. Commencez par des runs en commentaires seuls. Ils révèlent les cas limites de votre codebase. Traitez cette phase comme une validation avant la prod.
• Configuration des canaux Slack : les déclencheurs Slack ne fonctionnent que sur des canaux publics ; et le bot @Cursor doit être explicitement invité dans le canal.

Bonnes pratiques pour des automations fiables

• Une tâche par automation : chaque automation doit faire une chose bien définie. Les pannes sont plus simples à isoler, les correctifs à appliquer.
• Partir d’un état propre : validez votre arbre de travail avant de laisser un agent changer du code, pour avoir un diff net.
• Traiter les premiers runs comme une calibration : attendez-vous à un peu de bruit, révisez, ajustez, relancez jusqu’à stabilité.
• Des noms clairs et descriptifs : des noms comme PR Code Review – Open & Push – Comment Only sont plus utiles que des libellés génériques.
• Consulter l’historique souvent au début : vous forgez votre intuition du « normal », ce qui facilite la détection des anomalies.

Conclusion

Cursor Automations fait passer le codage avec agent d’un workflow interactif à un système piloté par événements. En mode Agent, nous ouvrons un chat et demandons à l’agent de relire, refactorer ou investiguer. Avec les automations, nous ne lançons plus directement le travail : des déclencheurs comme une PR, un message Slack ou une planification démarrent l’agent automatiquement, qui mène la tâche à son terme. Le changement majeur : le travail régulier passe d’une file d’attente manuelle à un système qui tourne en arrière-plan.

Dans cet article, je vous ai guidé pour construire deux automations : une relecture de PR et un suivi de couverture planifié. Elles sont volontairement simples, car elles offrent la bonne porte d’entrée pour observer le système sans complexité supplémentaire. Une fois à l’aise, vous pourrez implémenter des workflows avancés.

L’idée clé : commencez par une automation ciblée, écrivez des instructions comme un runbook, exécutez-la en mode peu risqué, et n’élargissez que lorsqu’elle se comporte de façon fiable. La valeur vient moins du nombre d’automations que de la constance de chacune.

Pour aller plus loin sur ce que nous avons couvert, voici nos prochaines étapes recommandées :

• Approfondissez votre maîtrise du mode Agent et du workflow Cursor avec notre cours Software Development with Cursor.
• Découvrez les nouveautés de Cursor 3.0.