Laisser un LLM examiner nos Pull Requests (pour que vous n’ayez pas à le faire)

Nous aimons l’automatisation. Nous l’utilisons pour alimenter notre infrastructure, pour réduire les charges de travail à zéro, et — de plus en plus — pour réduire l’attention humaine nécessaire à la livraison d’un code de haute qualité. Un domaine qui semblait encore obstinément manuel était les revues de pull requests. Entre Cursor comme IDE, ChatGPT/Codex pour le prototypage, et gemini-cli pour des vérifications rapides, nos workflows locaux étaient rapides — mais l’intégration continue attendait toujours un humain.

Nous avons donc posé une question simple : pouvait-on laisser un grand modèle linguistique lire le diff, repérer les problèmes, et commenter directement sur la PR ?

Il s’avère que oui. Il a suffi de quelques lignes de code glue GitHub Actions pour obtenir des revues structurées et utiles sur chaque pull request.

L’objectif

Nous ne cherchions pas à remplacer les humains. Nous voulions un premier passage qui :

• lise le diff réel d’une PR (pas le dépôt entier),
• signale les erreurs évidentes et les changements risqués,
• suggère des petites refactorisations ou des tests manquants,
• catégorise les constats par priorité,
• et poste les résultats là où on regarde déjà : dans la conversation de la PR et le résumé Actions.

Si un changement est correct, nous voulons que le bot le dise simplement et s’efface.

Les outils dans notre stack

• GitHub Actions pour l’orchestration CI.
• Cursor (notre IDE au quotidien).
• ChatGPT/Codex pour l’idéation et les revues rapides hors ligne.
• @google/gemini-cli dans CI pour exécuter l’étape de revue automatisée.
• La GitHub CLI (gh) pour commenter sur la PR.
• Un ingrédient petit mais crucial : un prompt qui oriente le modèle pour produire un retour utile et exploitable.

Le workflow, de bout en bout

Voici l’Action complète que nous utilisons. Placez-la dans .github/workflows/gemini-pr.yml :

name: gemini-pr
on:
  workflow_dispatch:
  pull_request:
jobs:
  build:
    permissions: write-all
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
      with:
        submodules: 'true'
        fetch-depth: 0
    - uses: actions-rust-lang/setup-rust-toolchain@v1
      with:
        components: rustfmt, clippy
        cache: false
    - uses: actions/setup-node@v4
      with:
        node-version: 20
    - name: install gemini
      run: |
        npm install -g @google/gemini-cli
    - name: gemini
      run: |
        echo "merging into ${{ github.base_ref }}"
        git diff origin/${{ github.base_ref }} > pr.diff
        echo $PROMPT | gemini -a > review.md
        cat review.md >> $GITHUB_STEP_SUMMARY
        gh pr comment ${{ github.event.pull_request.number }} --body-file review.md
      env:
        GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        PROMPT: >
          please review the changes of @pr.diff (this pull request) and suggest improvements or provide insights into potential issues. 
          do not document or comment on existing changes, if everything looks good, just say so.
          can you categorise the changes and improvesments into low, medium and high priority?
          Whenever you find an issue, please always provide an file and line number as reference information. if multiple files are affected, please provide a list of files and line numbers.
          provide the output in markdown format and do not include any other text.

Ce que chaque partie fait

• Checkout avec fetch-depth: 0 pour pouvoir comparer fiablement avec la branche de base de la PR.

• Rust toolchain installe rustfmt et clippy car nos dépôts contiennent souvent du code Rust ; ces outils tournent ailleurs dans notre pipeline, mais rester consistants évite des surprises.

• Node est nécessaire pour le gemini-cli.

• Nous installons @google/gemini-cli globalement dans le runner.

• Nous créons un fichier diff :

  git diff origin/${{ github.base_ref }} > pr.diff
  

  Cela garantit que le modèle ne voit que les changements à revoir.

• Nous piped le prompt dans gemini -a (le CLI lit @pr.diff inline en référence fichier) et capturons la sortie markdown du modèle dans review.md.

• Nous ajoutons la revue au résumé du job ($GITHUB_STEP_SUMMARY) pour qu’elle soit visible dans l’interface Actions.

• Nous commentons la PR via gh pr comment … --body-file review.md.

Le prompt qui rend cela utile

Les sorties d’un LLM ne sont aussi bonnes que les instructions. La nôtre reste pratique :

• Portée : Ne revoir que ce qui a changé. Pas besoin de redocumenter le dépôt.
• Signal : Dire “ça a l’air bon” quand il n’y a rien à ajouter. Pas de créativité forcée.
• Actionnabilité : Toujours inclure fichier + numéro de ligne pour les constats.
• Priorités : Classer en faible / moyen / élevé pour aider les reviewers à parcourir rapidement.
• Format : Markdown uniquement, pour coller proprement dans les commentaires PR et un rendu clair dans le résumé.

Nous avons itéré un peu pour arriver là. Les ajustements les plus impactants : insister sur les références fichier/ligne et interdire des propos superflus.

À quoi ressemble la revue

Sur une PR typique, on voit des sections comme :

• Élevé : Changements sensibles en sécurité, gestion d’erreurs cassée, validation d’entrée manquante, secrets accidentels, ou tests supprimés.
• Moyen : Cas limite, risques de concurrence, messages d’erreur douteux, Rust/Go/TS non idiomatique qui pourrait poser problème plus tard.
• Faible : Nommage, commentaires, petites refactorisations, ou suggestion d’un test rapide pour verrouiller un comportement.

Si tout va bien, on obtient une ligne : « Ça a l’air bon. » Parfait — c’est exactement ce qu’on veut.

Pièges et notes pratiques

• Secrets : Vous avez besoin de GEMINI_API_KEY et GITHUB_TOKEN dans les secrets du repo ou de l’organisation. Restreignez les scopes au strict nécessaire. L’Action définit permissions: write-all car elle poste un commentaire ; restreignez cela si votre politique l’exige.
• Source du diff : Pour les merges complexes, git diff origin/${{ github.base_ref }} donne le bon contexte. Si votre workflow ne récupère que le commit de merge, assurez-vous que la branche de base est accessible ou adaptez sur github.event.pull_request.base.sha.
• Forks : Si vous acceptez des PRs venant de forks, vérifiez la gestion des secrets. Vous pouvez vouloir exécuter ça sur pull_request_target avec une sécurisation poussée, ou conditionner la revue à des labels.
• Contrôle du bruit : Il est utile que le modèle ne dise rien au-delà de « ça a l’air bon » quand un changement est trivial. Ça réduit considérablement la fatigue des reviewers.
• Coûts et quotas : Les appels au modèle ont un coût. Nous limitons la taille du diff envoyé et exécutons cela uniquement sur pull_request (pas à chaque push).
• Confidentialité : Vous envoyez votre diff à un fournisseur de modèle externe. Si votre code est sensible ou soumis à restrictions à l’export, évaluez les risques et choisissez un fournisseur ou un modèle déployé qui correspond à vos exigences de conformité.

Pourquoi c’est important (au-delà de la commodité)

Les revues automatisées rendent les humains plus sélectifs dans leur attention. On passe moins de temps sur « renomme cette variable » et plus sur l’architecture, les flux de données, et les frontières de sécurité. Cela signifie :

• Des boucles de feedback plus rapides pour les contributeurs.
• Moins de cycles de revue pour des broutilles.
• Un historique de commits plus propre avec des problèmes détectés plus tôt.
• Plus de temps pour le travail de durabilité qui compte vraiment — comme réduire la consommation d’énergie d’un service ou diminuer la sortie réseau.

C’est aussi étonnamment bon pour la cohérence. Un LLM n’oubliera pas le pattern convenu de gestion d’erreur entre services ou notre structure préférée de logs ; il applique ces contrôles uniformément à chaque PR.

Variantes que vous pourriez essayer

Ce pattern fonctionne avec presque tous les modèles ou CLI. Quelques extensions simples :

• Vote multi-modèle : Appeler deux modèles avec le même prompt et ne garder que les constats sur lesquels ils sont d’accord.
• Passes sensibles au langage : Si votre repo mélange les langages, lancez des prompts spécifiques par langage (ex. un adapté à Rust avec des indices Clippy, un pour TypeScript).
• Portes “Fail on High” : Utilisez un petit parseur pour détecter une section “Élevé” et passer le job en failed pour bloquer les merges jusqu’à résolution.
• Revue inline : Convertir les références fichier/ligne en commentaires de revue GitHub (le CLI gh le permet) pour un retour encore plus précis.
• Contrôle par labels PR : Ne lancer que quand un mainteneur ajoute un label ai-review, ou ajouter automatiquement un label needs-attention quand des constats hautement prioritaires apparaissent.

Résultats jusqu’à présent

• Cycles de revue plus courts pour les changements simples.
• Diffs plus propres car les contributeurs corrigent les points basiques avant qu’un humain ne regarde.
• Meilleure intégration : les nouveaux reçoivent des conseils concrets qui reflètent ce que diraient les reviewers seniors.
• Pas de drame : si le bot n’a rien à ajouter, il reste silencieux.

Rien de tout cela ne remplace un humain pour valider un merge. C’est un filtre léger qui s’amortit dès le premier jour.