Passer au contenu principal
Ce tutoriel te montre comment configurer une revue de code avec Cursor CLI dans GitHub Actions. Le workflow analysera les pull requests, identifiera les problèmes et publiera des commentaires.
Pour la plupart des utilisateurs, on recommande plutôt d’utiliser Bugbot. Bugbot propose une revue de code automatisée gérée, sans aucune configuration. Cette approche via la CLI est utile pour explorer les capacités et pour des personnalisations avancées.
Exemple de revue de code automatisée avec des commentaires en ligne sur une pull request

Configurer l’authentification

Configure ta clé d’API et les secrets du dépôt pour authentifier Cursor CLI dans GitHub Actions.

Configurer les autorisations de l’agent

Crée un fichier de configuration pour contrôler les actions que l’agent peut effectuer. Ça évite des opérations non intentionnelles comme pousser du code ou créer des pull requests. Crée .cursor/cli.json à la racine de ton dépôt :
{
  "permissions": {
    "interdire": [
      "Shell(git push)",
      "Shell(gh pr create)",
      "Write(**)"
    ]
  }
}
Cette configuration permet à l’agent de lire des fichiers et d’utiliser l’outil en ligne de commande GitHub (CLI) pour les commentaires, mais l’empêche d’apporter des modifications à ton dépôt. Consulte la référence des autorisations pour davantage d’options de configuration.

Créer le workflow GitHub Actions

Construisons maintenant le workflow étape par étape.

Configurer le déclencheur du workflow

Crée le fichier .github/workflows/cursor-code-review.yml et configure-le pour s’exécuter sur les pull requests :
name: Revue de code Cursor

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

jobs:
  code-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    
    steps:

Récupère le dépôt

Ajoute l’étape de checkout pour accéder au code de la pull request :
- name: Récupérer le dépôt
  uses: actions/checkout@v4
  with:
    fetch-depth: 0
    ref: ${{ github.event.pull_request.head.sha }}

Installer le CLI Cursor

Ajoute l’étape d’installation du CLI :
- name: Installer l’interface CLI de Cursor
  run: |
    curl https://cursor.com/install -fsS | bash
    echo "$HOME/.cursor/bin" >> $GITHUB_PATH

Configurer l’agent de review

Avant d’implémenter l’étape de review complète, on va décortiquer l’anatomie de notre prompt de review. Cette section explique comment on veut que l’agent se comporte : Objectif : On veut que l’agent analyse le diff du PR actuel et ne signale que les problèmes clairs et à forte gravité, puis laisse de très courts commentaires inline (1–2 phrases) uniquement sur les lignes modifiées, avec un bref récap à la fin. Ça maintient un bon ratio signal/bruit. Format : On veut des commentaires courts et directs. On utilise des émojis pour faciliter le scan des commentaires, et on veut un récapitulatif global de la review complète à la fin. Soumission : Quand la review est terminée, on veut que l’agent ajoute un court commentaire basé sur ce qui a été trouvé pendant la review. L’agent doit soumettre une seule review contenant des commentaires inline plus un résumé concis. Cas limites : On doit gérer :
  • Commentaires existants résolus : l’agent doit les marquer comme terminés quand ils ont été adressés
  • Éviter les doublons : l’agent doit s’abstenir de commenter si un retour similaire existe déjà sur ou près des mêmes lignes
Prompt final : Le prompt complet combine toutes ces exigences de comportement pour produire un feedback ciblé et exploitable Maintenant, implémentons l’étape de l’agent de review :
- name: Effectuer une revue de code
  env:
    CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
    GH_TOKEN: ${{ github.token }}
  run: |
    cursor-agent --force --model "$MODEL" --output-format=text --print "Tu es en train d’exécuter un job GitHub Actions pour une revue de code automatisée. L’interface de ligne de commande gh est disponible et authentifiée via GH_TOKEN. Tu peux commenter les pull requests.
    
    Contexte :
    - Référentiel : ${{ github.repository }}
    - Numéro de PR : ${{ github.event.pull_request.number }}
    - SHA de tête de la PR : ${{ github.event.pull_request.head.sha }}
    - SHA de base de la PR : ${{ github.event.pull_request.base.sha }}
    
    Objectifs :
    1) Revoir les commentaires existants et répondre « Résolu » lorsqu’ils ont été pris en compte
    2) Examiner le diff actuel de la PR et ne relever que les problèmes évidents et de gravité élevée
    3) Laisser des commentaires en ligne très courts (1 à 2 phrases) uniquement sur les lignes modifiées, puis un bref résumé à la fin
    
    Procédure :
    - Récupérer les commentaires existants : gh pr view --json comments
    - Récupérer le diff : gh pr diff
    - Si un problème signalé précédemment semble corrigé par des changements proches, répondre : ✅ Ce problème semble avoir été résolu par les changements récents
    - Éviter les doublons : ignorer si un retour similaire existe déjà sur ou à proximité des mêmes lignes
    
    Règles de commentaire :
    - Maximum 10 commentaires en ligne au total ; prioriser les problèmes les plus critiques
    - Un seul problème par commentaire ; le placer exactement sur la ligne modifiée
    - Ton naturel, précis et exploitable ; ne pas mentionner l’automatisation ni un niveau de confiance élevé
    - Utiliser des émojis : 🚨 Critique 🔒 Sécurité ⚡ Performance ⚠️ Logique ✅ Résolu ✨ Amélioration
    
    Soumission :
    - Soumettre une seule revue contenant des commentaires en ligne plus un résumé concis
    - Utiliser uniquement : gh pr review --comment
    - Ne pas utiliser : gh pr review --approve ou --request-changes"
.
├── .cursor/
│   └── cli.json
├── .github/
│   └── workflows/
│       └── cursor-code-review.yml

Teste ton reviewer

Crée une pull request de test pour vérifier que le workflow fonctionne et que l’agent publie des commentaires de review avec des retours en émojis.
Pull request affichant des commentaires de review automatisés avec des émojis et des retours inline sur des lignes spécifiques

Prochaines étapes

Tu as maintenant un système automatisé de revue de code opérationnel. Pense à ces améliorations :
  • Mettre en place des workflows supplémentaires pour corriger les échecs CI
  • Configurer différents niveaux de revue selon les branches
  • Intégrer ça au processus de revue de code existant de ton équipe
  • Personnaliser le comportement de l’agent selon les types de fichiers ou les répertoires