Revue de code par IA dans GitHub Actions avec Claude et Gemini

15 min de lecture·Matthieu·ci-cdgeminiclaudeai-code-reviewgithub-actions|

Configurez Claude Code Action et Gemini pour la revue automatisée de pull requests. Workflows multi-modèles avec séparation des rôles, quality gates qui bloquent les merges sur les problèmes critiques, et durcissement contre l'injection de prompts.

La revue de code par IA est passée de l'expérimentation à l'outillage de production. Claude Code Action et Gemini Code Assist peuvent analyser chaque pull request automatiquement, en détectant des bugs logiques, des failles de sécurité et des erreurs de gestion d'erreurs que les linters et l'analyse statique ne voient pas.

Ce tutoriel configure les deux modèles sur le même dépôt. Claude gère la revue logique et sécurité. Gemini gère le style et la documentation. Un quality gate analyse la sévérité des deux revues et bloque les merges quand des problèmes critiques sont détectés.

AIOps sur un VPS : gestion de serveur par IA avec des outils open source

Qu'est-ce que la revue de code IA détecte que les linters ratent ?

Les linters vérifient la syntaxe et le formatage. Les outils d'analyse statique comme Semgrep détectent des patterns connus. Les revues de code par IA font autre chose : elles lisent le diff en contexte et raisonnent sur ce que le code fait. Elles signalent les conditions de course, les chemins de gestion d'erreurs manquants, les configurations par défaut non sécurisées et les erreurs de logique métier que les outils à base de patterns ne peuvent pas détecter.

Une étude de Milvus a testé cinq modèles d'IA sur la détection de bugs réels dans des PR en production. Le meilleur modèle individuel a détecté 53 % des bugs. Quand plusieurs modèles ont analysé la même PR et débattu des résultats entre eux, la détection est montée à 80 %. Les bugs les plus difficiles, ceux nécessitant une compréhension au niveau système des chaînes d'appels et de la propagation d'erreurs, ont atteint 100 % de détection en mode débat multi-modèles.

C'est cette étude qui justifie l'utilisation de deux modèles dans ce tutoriel.

Exemples concrets de ce que la revue IA détecte :

  • Des entrées utilisateur non validées qui traversent trois appels de fonction avant d'atteindre une requête en base de données
  • Des vérifications null manquantes quand une fonction retourne Optional<T> mais que l'appelant suppose qu'elle réussit toujours
  • Des secrets codés en dur dans des fichiers de configuration qui ressemblent à des valeurs par défaut mais sont de vrais identifiants
  • Des lacunes dans la gestion d'erreurs où un try/catch attrape une exception générique et l'avale silencieusement
  • Des conditions de course dans du code concurrent où un état partagé est modifié sans synchronisation

Comment configurer Claude Code Action pour la revue de pull requests ?

Claude Code Action est une GitHub Action maintenue par Anthropic qui exécute Claude sur votre runner GitHub. Elle lit les diffs de PR, publie des commentaires en ligne et peut aussi implémenter des correctifs. La configuration prend environ cinq minutes.

Installer l'application GitHub Claude

Rendez-vous sur github.com/apps/claude et installez-la sur votre dépôt ou organisation. Accordez-lui l'accès aux dépôts que vous souhaitez faire analyser. L'application nécessite ces permissions :

  • Contents : Read
  • Pull Requests : Read & Write
  • Issues : Read & Write (optionnel, pour le tri des issues)

Ajouter la clé API

Dans votre dépôt, allez dans Settings > Secrets and variables > Actions et créez un nouveau secret :

  • Name : ANTHROPIC_API_KEY
  • Value : Votre clé API Anthropic (commence par sk-ant-)

Ne commitez jamais de clés API dans votre dépôt. Si vous avez besoin d'un accès à l'échelle de l'organisation, utilisez des secrets d'environnement plutôt que des secrets de dépôt.

Créer le workflow

Créez .github/workflows/claude-review.yml :

name: Claude Code Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - "src/**"
      - "lib/**"
      - "app/**"
      - "config/**"
    paths-ignore:
      - "**/*.md"
      - "**/*.txt"
      - "docs/**"

concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      pull-requests: write
      id-token: write

    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            Review this pull request. Focus on:
            1. Security: injection flaws, auth bypass, hardcoded secrets, insecure defaults
            2. Logic errors: off-by-one, null dereference, race conditions, resource leaks
            3. Error handling: swallowed exceptions, missing retries, unclear error messages
            4. Performance: N+1 queries, unbounded loops, unnecessary allocations

            Skip cosmetic issues (formatting, naming style). Another reviewer handles those.

            Rate each finding as CRITICAL, HIGH, MEDIUM, or LOW.

            Use inline comments for specific code issues.
            Use a summary PR comment for overall assessment.

          claude_args: |
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Le filtre paths limite les revues aux changements de code source. Les PR qui ne touchent que la documentation sautent le workflow, ce qui économise les coûts API. Le bloc concurrency annule les revues en cours quand un nouveau commit est poussé sur la même PR, pour ne pas payer l'analyse de code obsolète.

La restriction --allowedTools est une mesure de sécurité. Elle limite Claude à la lecture des diffs et à la publication de commentaires. Il ne peut pas modifier de fichiers, exécuter des commandes arbitraires ou accéder à d'autres dépôts.

Comment ajouter la revue Gemini au même dépôt ?

Deux options pour la revue via Gemini : l'application GitHub Gemini Code Assist (gérée par Google, zéro YAML) ou la GitHub Action run-gemini-cli (auto-gérée, contrôle total). Ce tutoriel utilise la GitHub Action car elle donne le contrôle sur le prompt et s'intègre au workflow de quality gate.

Obtenir une clé API Gemini

Créez une clé sur Google AI Studio. Ajoutez-la comme secret du dépôt :

  • Name : GEMINI_API_KEY
  • Value : Votre clé API Gemini

Pour un usage entreprise avec l'authentification Vertex AI, consultez la documentation run-gemini-cli pour la configuration Workload Identity Federation.

Créer le workflow Gemini

Créez .github/workflows/gemini-review.yml :

name: Gemini Code Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - "src/**"
      - "lib/**"
      - "app/**"
      - "config/**"
    paths-ignore:
      - "**/*.md"
      - "**/*.txt"
      - "docs/**"

concurrency:
  group: gemini-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: read
      pull-requests: write

    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1

      - uses: google-github-actions/run-gemini-cli@main
        with:
          gemini_api_key: ${{ secrets.GEMINI_API_KEY }}
          prompt: |
            Review this pull request. Focus on:
            1. Code style: naming conventions, function length, complexity
            2. Documentation: missing docstrings, outdated comments, unclear variable names
            3. Test coverage: untested edge cases, missing assertions, test quality
            4. Maintainability: code duplication, tight coupling, violation of SOLID principles

            Skip security and logic analysis. Another reviewer handles those.

            Rate each finding as CRITICAL, HIGH, MEDIUM, or LOW.

            Post your review as a single PR comment with structured sections.

L'action run-gemini-cli est actuellement en bêta, c'est pourquoi le workflow pointe sur @main. Pour un usage en production, épinglez un SHA de commit spécifique (par ex. @abc1234) pour éviter les changements inattendus quand la branche main est mise à jour.

Pourquoi deux workflows séparés ?

Exécuter Claude et Gemini dans des fichiers de workflow distincts signifie qu'ils tournent en parallèle. Un échec de l'un ne bloque pas l'autre. Vous pouvez aussi désactiver temporairement un modèle sans toucher à l'autre workflow.

La séparation des rôles est intentionnelle. Claude a tendance à suivre les chaînes d'appels de bout en bout et excelle dans la détection des lacunes de gestion d'erreurs et des failles de sécurité. Gemini est performant sur le style de code, la complétude de la documentation et les patterns structurels. Le chevauchement est normal. L'accord entre modèles renforce la confiance dans les résultats.

Comment fonctionne la revue multi-modèles avec Claude et Gemini ensemble ?

La configuration à deux workflows ci-dessus implémente déjà la revue multi-modèles. Les deux modèles analysent la même PR indépendamment et publient des commentaires séparés. C'est le pattern le plus simple et il fonctionne bien pour la plupart des équipes.

Pour les équipes qui veulent une vue unifiée, ajoutez une étape d'agrégation. Ce troisième workflow s'exécute après la fin des deux revues et publie un résumé combiné :

name: AI Review Summary

on:
  workflow_run:
    workflows: ["Claude Code Review", "Gemini Code Review"]
    types: [completed]

jobs:
  aggregate:
    if: github.event.workflow_run.event == 'pull_request'
    runs-on: ubuntu-latest
    timeout-minutes: 5
    permissions:
      pull-requests: write
      actions: read

    steps:
      - name: Collect review comments
        id: collect
        uses: actions/github-script@v7
        with:
          script: |
            const pr_number = context.payload.workflow_run.pull_requests[0]?.number;
            if (!pr_number) return;

            const comments = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: pr_number,
            });

            const aiComments = comments.data.filter(c =>
              c.body.includes('CRITICAL') ||
              c.body.includes('HIGH') ||
              c.body.includes('MEDIUM')
            );

            const critical = aiComments.filter(c => c.body.includes('CRITICAL')).length;
            const high = aiComments.filter(c => c.body.includes('HIGH')).length;

            const summary = `## AI Review Summary\n\n` +
              `| Severity | Count |\n|----------|-------|\n` +
              `| CRITICAL | ${critical} |\n` +
              `| HIGH | ${high} |\n\n` +
              (critical > 0 ? '⛔ **Merge blocked:** Critical findings require human review.\n' :
               high > 0 ? '⚠️ High-severity findings detected. Review recommended before merge.\n' :
               '✅ No critical or high-severity findings.\n');

            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: pr_number,
              body: summary,
            });

            core.setOutput('critical_count', critical);

      - name: Set status check
        if: steps.collect.outputs.critical_count > 0
        run: exit 1

C'est un point de départ. Adaptez la logique d'analyse des commentaires au format exact que vos prompts produisent. Les mots-clés de sévérité (CRITICAL, HIGH, MEDIUM) dans les prompts de revue rendent le parsing direct.

Comment bloquer les merges quand la revue IA trouve des problèmes critiques ?

Le workflow d'agrégation ci-dessus retourne le code de sortie 1 quand des problèmes critiques existent. Pour en faire un bloqueur de merge, configurez la protection de branche :

  1. Allez dans Settings > Branches > Branch protection rules
  2. Sélectionnez ou créez une règle pour votre branche principale
  3. Activez Require status checks to pass before merging
  4. Recherchez et ajoutez << AI Review Summary >> comme status check requis
Sévérité Action Merge bloqué ?
CRITICAL Échec du status check Oui
HIGH Avertissement dans le résumé Non (consultatif)
MEDIUM Listé dans le résumé Non
LOW Omis du résumé Non

Attention toutefois : les reviewers IA produisent des faux positifs. Si vous rendez le status check obligatoire, les développeurs devront parfois rejeter des résultats erronés. Gardez CRITICAL comme seule sévérité bloquante. Si vous bloquez aussi sur HIGH, attendez-vous à des frictions.

Pour contourner un merge bloqué, un mainteneur peut utiliser le bypass admin sur la règle de protection de branche, ou vous pouvez ajouter un gestionnaire de commentaire /dismiss-ai-review qui relance le workflow de résumé avec un flag de passage forcé.

Comment réduire les faux positifs dans la revue de code IA ?

Les faux positifs sont la plainte principale des équipes utilisant la revue de code par IA. Des revues bruyantes érodent la confiance rapidement. Trois techniques aident.

Cadrer le prompt précisément

Les prompts ci-dessus le font déjà : Claude analyse la sécurité et la logique, Gemini analyse le style et la documentation. Un modèle à qui on demande de << tout analyser >> produit plus de bruit qu'un modèle avec un mandat spécifique.

Ajoutez du contexte spécifique au projet pour réduire davantage les faux positifs. Créez un fichier CLAUDE.md à la racine de votre dépôt (Claude Code Action le lit automatiquement) :

# Project Context

This is a Django REST API. Python 3.12. PostgreSQL.

## Review Guidelines
- We use `rest_framework.exceptions` for all error handling. Do not flag bare `except` blocks in middleware.
- `settings.py` contains environment variable references, not hardcoded secrets. Do not flag `os.environ.get()` calls.
- We intentionally use `Any` type hints in the serializer layer. Do not flag these.
- Test files use `pytest` fixtures. Do not flag unused function parameters in test files.

Pour Gemini, créez un fichier GEMINI.md à la racine du dépôt avec un contexte projet équivalent.

Filtrer les fichiers

Les filtres paths et paths-ignore dans le YAML du workflow empêchent les revues de fichiers qui génèrent du bruit :

paths-ignore:
  - "**/*.md"
  - "**/*.txt"
  - "**/*.lock"
  - "**/*.generated.*"
  - "migrations/**"
  - "vendor/**"
  - "dist/**"
  - "__snapshots__/**"

Les fichiers lock, le code généré, les dépendances vendored et les fichiers de migration produisent des faux positifs parce qu'ils sont générés par des machines ou suivent des patterns que le modèle ne comprend pas en contexte.

Définir un seuil de sévérité

Si vous ne faites remonter que les résultats CRITICAL et HIGH dans le résumé, le bruit MEDIUM et LOW n'atteint jamais le développeur. C'est un meilleur défaut que de tout afficher et demander aux développeurs d'ignorer le bruit.

Quels sont les risques de sécurité de la revue de code IA sur les pull requests ?

Les reviewers de code IA traitent des entrées non fiables. Le diff de la PR, les messages de commit, les titres d'issues et le contenu des fichiers sont tous contrôlés par l'attaquant dans les dépôts open source ou quand on accepte des contributions externes. Cela crée un risque d'injection de prompts (prompt injection).

L'attaque Clinejection

En février 2026, un attaquant a exploité le bot de triage Cline via une injection de prompt indirecte. L'attaque était simple : un titre d'issue GitHub malveillant contenait des instructions déguisées en message d'erreur. Le workflow de l'agent IA interpolait le titre de l'issue directement dans le prompt. L'agent a suivi les instructions injectées, exécuté npm install sur un paquet malveillant et exfiltré la clé ANTHROPIC_API_KEY de l'environnement CI.

L'attaque a compromis environ 4 000 machines de développeurs avant que le paquet malveillant ne soit retiré.

Durcir vos workflows

Restreignez les permissions des outils. Le flag --allowedTools dans le workflow Claude ci-dessus limite ce que Claude peut faire. Il peut lire les diffs et publier des commentaires. Il ne peut pas exécuter de commandes shell arbitraires, écrire des fichiers ou accéder à des secrets. C'est la mesure d'atténuation la plus efficace.

claude_args: |
  --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Sans cette restriction, un diff de PR forgé pourrait instruire Claude d'exécuter des commandes sur le runner.

N'interpolez jamais des entrées non fiables dans les prompts. N'utilisez pas ${{ github.event.issue.title }} ou ${{ github.event.pull_request.body }} dans le champ prompt. Passez le dépôt et le numéro de PR, et laissez l'action récupérer le contenu via l'API GitHub.

Gérez les PR de forks avec prudence. Les PR de forks s'exécutent avec des permissions GITHUB_TOKEN réduites par défaut, mais vos secrets restent disponibles pour le workflow s'il est déclenché par pull_request_target. Utilisez pull_request (pas pull_request_target) pour les workflows de revue IA. Les PR de forks ne peuvent donc pas accéder à vos clés API et la revue ne s'exécutera pas, ce qui est le comportement sûr par défaut.

on:
  pull_request:        # Safe: fork PRs cannot access secrets
    types: [opened, synchronize]
  # pull_request_target:  # Dangerous: fork PRs CAN access secrets

Faites tourner vos clés API. Si une clé est exposée via un log CI ou un runner compromis, le rayon d'impact est limité au temps entre les rotations. Faites tourner les clés au minimum chaque trimestre.

Auditez les exécutions de workflows. Vérifiez l'onglet Actions périodiquement pour des durées d'exécution inhabituelles ou des invocations d'outils inattendues. Une revue qui prend 45 minutes au lieu des 3 minutes habituelles peut indiquer que le modèle est manipulé.

Combien coûte la revue de code IA par pull request ?

Le coût évolue avec la taille de la PR. Claude et Gemini facturent au token traité. Les tokens d'entrée incluent le diff de la PR, le contexte des fichiers et votre prompt. Les tokens de sortie sont les commentaires de revue.

Taille de PR Diff typique (lignes) Tokens d'entrée estimés
Petite 50-100 2 000-5 000
Moyenne 200-500 8 000-20 000
Grande 500-1 500 20 000-60 000

Le nombre de tokens varie selon le langage. Un diff Python de 200 lignes consomme moins de tokens qu'un diff Java de 200 lignes car Java est plus verbeux.

Utiliser deux modèles double le coût en tokens mais pas le coût en euros, car la tarification diffère entre fournisseurs. Consultez les tarifs par token actuels sur la page de tarification Anthropic et la page de tarification Google AI. Les deux utilisent une tarification au token avec des taux différents pour les tokens d'entrée et de sortie.

Pour estimer votre budget mensuel : multipliez la taille moyenne de vos PR (en tokens) par le nombre de PR par mois, puis multipliez par le taux au token pour chaque modèle. Une équipe qui merge 50 PR par semaine avec des diffs de taille moyenne peut calculer :

weekly_cost = 50 * avg_tokens_per_pr * (claude_input_rate + gemini_input_rate)
              + 50 * avg_output_tokens * (claude_output_rate + gemini_output_rate)

Réduire les coûts

  • Les filtres de chemins empêchent les revues de docs, fichiers lock et code généré. C'est l'économie la plus significative.
  • L'annulation par concurrence arrête l'analyse de commits obsolètes quand un nouveau push arrive.
  • Ignorez les PR en brouillon en n'incluant pas ready_for_review dans vos types de déclenchement, puis ajoutez-le seulement quand vous voulez des revues sur les transitions brouillon-vers-prêt.
  • Utilisez des modèles plus petits pour la revue de style. Gemini Flash est moins cher que Gemini Pro pour les vérifications de style et de documentation où le raisonnement approfondi n'est pas nécessaire.

Comparaison : outils de revue de code IA

Fonctionnalité Claude Code Action Gemini Code Assist CodeRabbit GitHub Copilot
Méthode de configuration GitHub Action (YAML) GitHub App ou Action GitHub App Intégré
Modèle de tarification Par token (API) Par token ou offre gratuite Abonnement par dépôt Abonnement par poste
Commentaires en ligne Oui Oui Oui Oui
Prompts personnalisés Contrôle total Contrôle total (Action) Fichier de config Limité
Runner auto-hébergé Oui Oui (Action) Non Non
Support multi-modèles Combinable Combinable Modèle unique Modèle unique
Open source Oui (MIT) Oui (Action) Non Non

Claude Code Action et l'action Gemini CLI sont open source et tournent sur vos propres runners. Votre code ne quitte jamais votre infrastructure sauf pour l'appel API au fournisseur de modèle. CodeRabbit et Copilot sont des services managés où le code est traité sur leur infrastructure.

Quelles sont les limites de la revue de code IA ?

La revue de code par IA ne remplace pas la revue humaine. C'est une première passe qui détecte les problèmes courants et libère les reviewers humains pour se concentrer sur l'architecture, le design et les décisions de logique métier.

Limites de la fenêtre de contexte. Les grosses PR (plus de 1 500 lignes modifiées) peuvent dépasser la fenêtre de contexte du modèle ou produire des revues superficielles parce que le modèle ne peut pas garder l'intégralité du diff en contexte. Découpez les grosses PR en plus petites. C'est une bonne pratique indépendamment de la revue IA.

Pas de compréhension à l'exécution. Les reviewers IA voient du code statique. Ils ne peuvent pas détecter les problèmes qui ne se manifestent qu'à l'exécution : fuites mémoire sous charge, conditions de course dépendantes du timing ou dégradation de performance à grande échelle.

Les faux positifs sont inévitables. Même avec des prompts bien cadrés et des fichiers de contexte projet, les modèles signaleront du code correct. Prévoyez 10 à 20 % de faux positifs dans les résultats. Si le taux est plus élevé, resserrez vos prompts et ajoutez plus de contexte à CLAUDE.md ou GEMINI.md.

Pas de connaissance institutionnelle. Le modèle ne connaît pas les conventions non écrites de votre équipe, les décisions historiques ou les patterns spécifiques à votre domaine, sauf si vous les documentez dans les fichiers de contexte. Investissez du temps à écrire de bons fichiers CLAUDE.md et GEMINI.md. L'effort se rentabilise à chaque revue.

Déterminisme. La même PR analysée deux fois peut produire des résultats différents. La revue IA est probabiliste. Ne traitez pas << aucun résultat >> comme << aucun bug >>.

Dépannage

Le workflow de revue Claude ne se déclenche jamais. Vérifiez le filtre paths. Si votre code source se trouve en dehors de src/, lib/ ou app/, ajustez les chemins pour correspondre à la structure de votre projet. Vérifiez aussi que l'application GitHub Claude est installée sur le dépôt.

Gemini retourne des revues vides. Confirmez que le secret GEMINI_API_KEY est défini et que la clé est valide. Testez-la localement :

curl -s "https://generativelanguage.googleapis.com/v1beta/models?key=YOUR_KEY" | head -20

Si vous voyez une liste de modèles, la clé fonctionne.

Les revues prennent trop de temps. Le paramètre timeout-minutes: 15 arrête le workflow s'il dépasse 15 minutes. Les grosses PR de plus de 1 000 lignes peuvent prendre 5 à 10 minutes. Si les timeouts sont fréquents, resserrez le filtre paths pour réduire la taille du diff.

Trop de faux positifs. Ajoutez du contexte projet à CLAUDE.md et GEMINI.md. Soyez spécifique sur les patterns que le modèle doit ignorer. << Ne pas signaler X >> est plus efficace que << soyez indulgent >>.

Le status check reste en attente. Le workflow d'agrégation se déclenche à la complétion de workflow_run. Si l'un des deux workflows de revue est ignoré (parce qu'aucun fichier correspondant n'a changé), l'agrégation peut ne pas se déclencher. Ajoutez un filtre paths au workflow d'agrégation qui couvre l'union des deux workflows de revue, ou utilisez un status check séparé qui s'exécute toujours.

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.

Prêt à essayer ?

Déployez votre serveur en quelques secondes. Linux, Windows ou FreeBSD.

Voir les offres VPS