Cursor Bugbot : configurer les revues de code et maîtriser les coûts

Mon avis : Bugbot mérite sa place dans votre sélection si l’équipe souhaite passer des problèmes signalés dans les PR au workflow de correction de Cursor. Conservez la validation humaine et vos contrôles automatisés habituels. Sur Azure DevOps, évaluez la revue pour ce qu’elle apporte à elle seule, car Bugbot Autofix n’y est pas disponible. Sur GitLab et Bitbucket, vérifiez que les corrections directement sur la branche de la PR conviennent à votre workflow avant d’activer Autofix.

Que vérifie Cursor Bugbot dans une pull request ?

Bugbot recherche les bugs, les problèmes de sécurité et les défauts de qualité du code dans le diff d’une pull request, c’est-à-dire les modifications proposées à la fusion. Imaginez un inspecteur chargé de contrôler des travaux de rénovation : il part des éléments modifiés, puis s’appuie sur les règles du dépôt pour connaître les exigences propres au bâtiment.

Les revues peuvent se lancer à chaque mise à jour de la PR ou lorsqu’une personne ajoute le commentaire cursor review ou bugbot run. Les commentaires déjà présents dans la discussion générale de la PR et sur les lignes de code lui donnent du contexte pour tenir compte des retours précédents. Les problèmes signalés sont accompagnés d’explications, de suggestions de correction et de liens pour poursuivre dans Cursor ou sur le Web. Fonctionnement de Bugbot.

L’intérêt concret est de repérer plus tôt un défaut qui aurait pu passer entre les mailles de la revue. Le nombre de commentaires ne mesure pas cette valeur. Pour juger les signalements, regardez s’ils identifient une défaillance réelle, expliquent quand elle se produit et débouchent sur une correction utile. Maintenez les tests, les analyses de sécurité et la revue par les responsables du code.

Configurer Bugbot dépôt par dépôt

Connectez votre plateforme de gestion de code depuis le tableau de bord des intégrations Cursor, puis ouvrez Bugbot dans Automations et activez les dépôts à examiner. La connexion de la plateforme et l’activation des dépôts sont deux étapes distinctes. Cursor prend en charge GitHub, GitLab, Bitbucket et Azure DevOps Services, ainsi que les variantes auto-hébergées documentées des trois premières plateformes. Configuration de Bugbot.

GitHub

Vous devez disposer des droits d’administration dans Cursor et dans l’organisation GitHub. Dans Integrations, cliquez sur Connect à côté de GitHub, ou sur Manage Connections si la connexion existe déjà. Choisissez All repositories ou Selected repositories, terminez la connexion, puis revenez dans Cursor pour activer les dépôts retenus dans Bugbot. GitHub Enterprise Server dispose de son propre onglet de configuration et de consignes réseau spécifiques. Intégration GitHub de Cursor.

GitLab

Pour GitLab.com, il faut des droits d’administration dans Cursor, le rôle Maintainer dans GitLab et un abonnement payant GitLab Premium ou Ultimate. Cursor exige des jetons d’accès de projet, que GitLab Free ne fournit pas. Dans Integrations, choisissez Connect ou Manage Connections, terminez l’installation GitLab, puis utilisez Manage → Sync Repos avant d’activer les dépôts dans Bugbot. Les installations auto-hébergées suivent des instructions de connexion distinctes. Intégration GitLab de Cursor.

Bitbucket

Bitbucket Cloud est actuellement en bêta publique. Connectez votre compte depuis Integrations et autorisez Cursor. L’espace de travail doit aussi disposer de l’application Cursor : un administrateur de cet espace ouvre le menu de gestion Bitbucket dans Cursor, choisit Install Cursor app, puis installe l’application dans l’espace de travail. Un administrateur de l’équipe Cursor ayant accès à cet espace ouvre ensuite Forge Apps → Cursor dans les paramètres de l’espace de travail Bitbucket, sélectionne Connect to Cursor et associe l’équipe. Activez ensuite les dépôts dans Bugbot. La seule connexion d’un compte personnel ne suffit pas à créer l’identité applicative utilisée pour les commentaires de revue. Bitbucket Data Center suit une procédure de configuration distincte. Intégration Bitbucket de Cursor.

Azure DevOps

Suivez la procédure propre à Bugbot pour Azure DevOps Services. Elle nécessite le consentement d’un administrateur du tenant Microsoft Entra. Un Project Collection Administrator connecte Azure DevOps et active Bugbot pour un dépôt, ce qui crée le principal de service de Cursor, une identité applicative dans votre organisation. Pour chaque projet à examiner, un administrateur du projet doit ajouter cette identité au groupe Project Administrators afin qu’elle puisse gérer les service hooks, les notifications qui déclenchent les revues.

La propagation des changements de droits peut prendre du temps. Corrigez toute erreur de configuration, puis réessayez d’activer le dépôt. Bugbot prend en charge les dépôts d’équipe, mais pas les dépôts rattachés à un périmètre personnel. Configuration de Bugbot pour Azure DevOps dans Cursor.

Choisir quand et pour qui lancer les revues

Pour chaque dépôt activé, décidez si Bugbot doit examiner les mises à jour ou intervenir une seule fois par PR, puis configurez les éventuelles listes d’auteurs autorisés ou exclus. Les paramètres personnels permettent de limiter les revues d’un auteur aux déclenchements par mention, à une seule revue par PR, ou d’inclure les brouillons. Sur les dépôts activés, Bugbot peut examiner les contributions de personnes extérieures à votre équipe Cursor. Paramètres des dépôts et paramètres personnels.

Azure DevOps impose une condition supplémentaire pour le déclenchement manuel : l’adresse de connexion Azure DevOps de la personne qui commente doit correspondre à un compte Cursor membre de l’équipe propriétaire du dépôt. Cette restriction ne s’applique pas aux revues automatiques. Déclenchement des revues sur Azure DevOps.

Le fichier .cursor/config/bugbot.yaml à utiliser

Placez les paramètres de revue dans le dépôt si vous voulez que leur modification passe elle aussi par une revue de code. Voici l’exemple publié dans la documentation Cursor sur la configuration des dépôts :

# .cursor/config/bugbot.yaml
version: 1

triggers:
  drafts: false
  frequency: everyPush # everyPush | oncePerPr

review:
  effort: default # low | default | high | smart
  smartPrompt: ""
  incremental: true

prSummary:
  mode: comment # disabled | description | comment
  riskScore: true

autofix:
  mode: disabled # disabled | newBranch | existingBranch

Commitez et poussez le fichier à cet emplacement, à partir de la racine du dépôt. Bugbot le lit sur la branche cible de la PR, celle qui recevra les modifications. Il n’utilise pas la version présente sur la branche source de la PR : une modification proposée ne peut donc pas réécrire sa propre configuration de revue. Utilisez CODEOWNERS, le mécanisme qui désigne les responsables des fichiers du dépôt, pour contrôler qui examine les changements de configuration.

Tous les champs sont facultatifs. Si un champ manque ou n’est pas valide, Bugbot passe à la source de paramètres suivante ; les fichiers de plus de 64 KB sont ignorés. L’ordre de priorité est le suivant :

1. Les réglages personnels de l’auteur pour ses propres PR.
2. Le fichier YAML du dépôt.
3. Les paramètres de l’équipe et de l’organisation dans le tableau de bord.

Cet ordre a une conséquence directe : la lecture du YAML ne suffit pas à établir quels paramètres s’appliqueront à un auteur. De plus, autofix.mode peut restreindre ce que le tableau de bord autorise, mais ne peut pas activer Autofix si le tableau de bord l’a désactivé. Fonctionnement et priorité des paramètres.

L’exemple choisit de publier le résumé dans un commentaire ; il ne présente pas l’ensemble des valeurs par défaut du tableau de bord. Sans ce réglage, les résumés de PR sont placés par défaut dans la description. La revue incrémentale examine les changements intervenus depuis la dernière revue Bugbot. Un niveau d’effort supérieur peut consacrer davantage de temps et de ressources facturées à la recherche de bugs ; le mode Smart détermine ce niveau à partir de vos instructions. Résumés, revues incrémentales et niveau d’effort.

Rédiger les consignes de revue dans BUGBOT.md

Utilisez .cursor/BUGBOT.md pour transmettre les connaissances du projet nécessaires à la revue. Le fichier à la racine est toujours inclus. Bugbot trouve aussi les fichiers .cursor/BUGBOT.md imbriqués en remontant l’arborescence depuis les fichiers modifiés : un répertoire backend peut ainsi porter des consignes différentes de celles du frontend. Les règles de l’éditeur Cursor dans .cursor/rules/*.mdc ne s’appliquent pas à Bugbot. Règles de projet de Bugbot.

Une règle utile précise un invariant et la défaillance à surveiller. Une équipe chargée des paiements peut, par exemple, indiquer qu’une nouvelle tentative d’exécution d’une opération ne doit pas débiter le client une seconde fois. Une équipe backend peut expliquer quelles transitions d’état exigent une entrée dans le journal d’audit. Ce sont des pistes pour rédiger les règles, pas une garantie que Bugbot détectera chaque violation.

Les règles d’équipe, les fichiers de règles du projet, les règles apprises et les règles manuelles du dépôt se cumulent. Pour utiliser les règles apprises et manuelles du tableau de bord, l’apprentissage doit être activé pour l’organisation et le dépôt. Restez précis : chaque règle est tronquée à 30 000 caractères, et l’ensemble des règles de revue est limité à 100 000 caractères. Pour vérifier ce qui a réellement été chargé, ajoutez le commentaire bugbot run verbose=true ou cursor review verbose=true ; la réponse indique les règles incluses, tronquées ou omises. Règles et limites.

Comment Bugbot est-il facturé aujourd’hui ?

Prévoyez le budget Bugbot en fonction de l’usage, en comptabilisant Autofix séparément. Voici la formulation actuelle de Cursor, traduite en français :

Il s’agit des conditions de facturation actuelles de Bugbot. Ne partez pas du principe que l’enveloppe d’utilisation de l’éditeur allouée à l’équipe couvre les revues Bugbot. Autofix consomme des crédits Cloud Agent, facturés aux tarifs de votre abonnement existant. Facturation d’Autofix.

Le changement tarifaire de mai s’applique aux abonnements existants à leur prochain renouvellement après le 8 juin 2026. Un ancien abonnement annuel peut donc conserver ses conditions précédentes jusqu’à son renouvellement. Annonce du changement tarifaire par Cursor.

La documentation actuelle de Bugbot ne donne aucun tarif fixe par revue à intégrer tel quel dans votre budget. La complexité des PR, la fréquence des revues et le niveau d’effort influent sur le travail effectué. Considérez le coût moyen d’une exécution communiqué par un fournisseur comme un repère, pas comme un tarif garanti pour votre dépôt.

Pour évaluer l’intérêt économique, comparez les dépenses de revue + les dépenses Autofix + le temps passé par les ingénieurs à évaluer les signalements avec le travail de revue et de reprise évité à l’équipe. Le budget de revue humaine reste nécessaire. La décision dépend des problèmes utiles repérés et de l’attention économisée, pas de la capacité d’un bot supplémentaire à produire des commentaires.

Autofix et MCP : des prérequis différents

Autofix lance un Cloud Agent, un agent qui intervient à distance sur le code, pour traiter les problèmes signalés par Bugbot et rendre compte de son travail dans la PR. L’utilisation à la demande et le stockage doivent être activés ; Legacy Privacy Mode ne satisfait pas cette exigence de stockage. Choisissez un mode pris en charge dans Bugbot Automations. Prérequis d’Autofix.

Ce sont les modes Autofix documentés par Cursor. Le mode sur branche existante autorise au maximum 3 tentatives par PR pour éviter les boucles. Je recommande de laisser Autofix désactivé tant que l’équipe n’a pas défini comment examiner les corrections générées. Les équipes sur GitHub peuvent ensuite choisir le mode sur nouvelle branche pour les inspecter séparément.

MCP est un protocole qui donne à un outil d’IA accès à d’autres outils et à du contexte. Il peut enrichir le processus de revue de Bugbot. Configurez le serveur MCP, puis ajoutez ses outils à Bugbot dans Automations. La prise en charge de MCP par Bugbot est réservée aux offres Team et Enterprise. Disponibilité de MCP.

Bugbot, CodeRabbit ou Greptile : lequel retenir ?

Choisissez selon l’adéquation avec votre workflow et le modèle de coût que vous pouvez maîtriser. Les tarifs ci-dessous sont ceux publiés par les éditeurs ; ils ne proviennent pas d’un test comparatif.

Sources : Cursor Bugbot, tarifs CodeRabbit, tarifs Greptile. Les montants annuels de CodeRabbit sont des équivalents mensuels avec facturation annuelle. Les crédits Greptile ne sont pas interchangeables avec l’usage Cursor ni avec les frais par fichier examiné de CodeRabbit.

Les différences budgétaires sont claires : CodeRabbit associe un abonnement par siège à d’éventuels frais de revue supplémentaires ; Greptile combine sièges et crédits ; le modèle actuel de Bugbot fait de l’usage des revues la variable centrale. Les seuls prix par siège ne permettent pas de désigner honnêtement l’option la moins chère pour votre équipe.

Pour une comparaison plus ciblée, consultez Greptile vs CodeRabbit. Pour élargir votre sélection, lisez les alternatives à CodeRabbit et les meilleurs outils de revue de code par IA pour les petites équipes.

Dans quels cas une équipe peut-elle en tirer le plus de valeur ?

Je privilégierais les workflows où un défaut non détecté coûte davantage que l’attention nécessaire pour évaluer un signalement. Les usages possibles ci-dessous sont classés dans l’ordre où je commencerais ; il ne s’agit pas de résultats mesurés.

Les mécanismes de revue, de contexte, de règles et d’Autofix sur lesquels reposent ces exemples sont documentés dans le guide Bugbot de Cursor. Leur valeur dépend de votre code et des personnes qui le relisent.

Quels outils complémentaires construire autour de Bugbot ?

La piste la plus solide consiste à aider un responsable technique à comprendre le coût des revues et leurs résultats. Proposer un générateur de commentaires supplémentaire est plus difficile à défendre quand des outils établis assurent déjà la revue.

Un tableau de suivi des coûts et des résultats

Une équipe plateforme pourrait créer un tableau de bord reliant les dépenses par dépôt aux problèmes que les ingénieurs ont confirmés, écartés ou corrigés. Les acheteurs visés seraient les responsables techniques. Le tarif Pro de Greptile à $30/siège/mois atteste l’existence d’un marché payant de la revue de code ; il ne prouve pas que ces clients paieraient pour cet outil complémentaire. Tarifs Greptile.

La version minimale utile rapprocherait les signalements et les données de facturation d’une appréciation humaine de leur utilité. L’API de revue Enterprise de Cursor expose des données d’analyse, dont les problèmes signalés et le coût facturé ; le champ de coût peut ne contenir aucun montant facturé. Une version destinée aux comptes non Enterprise devrait s’appuyer sur des saisies manuelles autorisées, sans présumer d’un accès à cette API. API et données d’analyse de Bugbot.

La limite : les commentaires résolus reflètent imparfaitement les bugs dont la détection a de la valeur, et une attribution incomplète des dépenses peut rendre le tableau de bord trompeur. C’est l’outil que je construirais en premier, car il répond à la question récurrente au renouvellement : cet outil de revue justifie-t-il son coût total ?

Un outil d’audit des politiques de revue des dépôts

Une équipe d’ingénierie plateforme pourrait utiliser un outil qui vérifie la conformité des dépôts à la configuration Bugbot approuvée, repère les règles de projet manquantes et signale les changements de politique non examinés. Le prix mensuel de CodeRabbit Team, $60/développeur/mois, montre que la gestion des revues en équipe s’inscrit dans une catégorie de produits payants ; l’intérêt pour un outil de politique de revue distinct resterait à valider. Tarifs CodeRabbit.

La version minimale pourrait lire les fichiers des dépôts et produire un rapport à examiner par leurs responsables. La limite : les paramètres personnels priment sur le YAML ; un audit des fichiers ne peut donc pas, à lui seul, certifier le comportement réel des revues. Rendez cette limite explicite et intégrez les paramètres du tableau de bord au processus lorsque les accès autorisés le permettent. Priorité des paramètres de Bugbot.

Garder une validation explicite avant la fusion

Rendre le contrôle Bugbot obligatoire ne signifie pas automatiquement que les problèmes non résolus bloquent la fusion. Par défaut, les signalements produisent un résultat neutre. Exiger le statut garantit l’exécution du contrôle ; lorsque l’option fail-on-unresolved-issues est disponible pour votre organisation, elle transforme les problèmes signalés en statut d’échec. Vérifiez ce réglage avant de vous reposer sur la protection des branches. Statuts des contrôles Bugbot.

Je recommande de considérer Bugbot comme une source d’informations supplémentaire pour la personne qui effectue la revue. Un rapport sans problème ne démontre pas que la fonctionnalité répond aux exigences, et un correctif généré automatiquement mérite le même examen que tout autre code.

Par quoi commencer lundi ?

Choisissez un dépôt dont les responsables peuvent définir les défaillances qu’ils veulent repérer. Faites terminer la connexion à la plateforme par l’administrateur concerné, activez Bugbot pour ce dépôt, commitez la configuration sur la branche cible et rédigez des règles de revue précises. Désignez la personne responsable du budget et traitez l’activation d’Autofix comme une décision distincte. Avant d’étendre le déploiement, profitez des revues habituelles pour consigner les signalements utiles, les suggestions écartées et le temps passé à évaluer les uns comme les autres.

Pour intégrer le suivi des revues ou le contrôle des dépôts à votre workflow de livraison, nous pouvons vous accompagner dans l’automatisation par IA.