Claude Code GitHub Actions : automatisez les revues de PR

Le vrai changement, c’est la disponibilité demandée au développeur. Auparavant, il fallait ouvrir le dépôt, lancer Claude, reporter le résultat dans GitHub et maintenir la session locale ouverte. Avec une Action, le responsable du dépôt laisse une demande bien délimitée et retrouve ensuite un commentaire ou une proposition de modification. Le travail peut démarrer en dehors des horaires de ce développeur ; la vérification du résultat prend toujours du temps.

Ce guide s’appuie sur la documentation actuelle d’Anthropic, consultée le 15 octobre 2026. Le workflow ci-dessous propose une configuration de départ volontairement restrictive. Il ne prétend pas que tous les tickets peuvent être résolus sans supervision.

Claude Code GitHub Actions : un assistant pour le dépôt

Voyez la GitHub App comme un badge d’accès, le workflow comme une fiche de mission et le runner comme un poste de travail temporaire. Un workflow est le fichier de configuration qui indique à GitHub quand démarrer ; le runner est la machine qui l’exécute.

L’action peut répondre aux mentions dans les issues et les pull requests. Si vous lui fournissez un prompt, elle devient une tâche automatisée. Pour une petite équipe, les demandes explicites sont le moyen le plus simple de repérer les tâches utiles avant de payer une revue à chaque modification. Utilisation de l’action.

Installez l’application, puis fusionnez le workflow

Utilisez l’installation guidée avec un compte disposant des droits d’administration sur le dépôt. Authentifiez l’outil GitHub CLI installé avec gh auth login, ouvrez claude dans le dépôt, puis lancez /install-github-app. Choisissez les workflows et l’authentification par clé API ou par abonnement, puis créez et fusionnez la PR contenant le workflow préparé. L’installation se fait en local ; les tâches suivantes s’exécutent sur GitHub. Installation rapide officielle.

L’installation manuelle aboutit au même résultat :

1. Installez la Claude GitHub App sur le dépôt choisi.
2. Dans le dépôt, ouvrez Settings → Secrets and variables → Actions, puis ajoutez l’un des secrets d’authentification du tableau ci-dessous.
3. Copiez l’exemple fonctionnel d’Anthropic dans .github/workflows/claude.yml, sélectionnez le paramètre d’authentification correspondant, puis fusionnez le fichier.
4. Publiez un commentaire contenant @claude et une demande précise.

Ce sont les étapes officielles de l’installation manuelle, avec le choix de l’identifiant d’authentification rendu explicite. Guide d’installation de l’action.

Pour utiliser votre abonnement, lancez claude setup-token en local et enregistrez le résultat dans le secret. Anthropic documente cette méthode pour les offres Pro, Max, Team et Enterprise. Le jeton généré est valable un an : désignez donc la personne chargée de le renouveler. Authentification par jeton.

La facturation dépend de l’identifiant utilisé : les exécutions avec une clé API relèvent de la facturation API ; celles avec un jeton OAuth consomment votre abonnement Claude. L’utilisation des runners GitHub Actions est comptabilisée séparément. Un jeton d’abonnement appartient à la personne qui l’a généré ; Anthropic recommande une clé API pour les secrets partagés entre plusieurs dépôts. Authentification et coûts.

La configuration par défaut de l’application ne nécessite pas de jeton d’accès personnel GitHub. L’accès à GitHub et l’authentification auprès de Claude sont distincts : l’application fournit le premier, le secret choisi assure la seconde. Paramètres d’authentification.

Commencez par un workflow limité, déclenché par une mention

Réservez ce profil aux dépôts d’équipe de confiance et aux petites modifications de fichiers. Il peut lire et modifier des fichiers, puis créer des commits via l’API GitHub. Claude ne dispose d’aucun outil shell : il ne peut donc pas lancer vos commandes de test avec ce profil. Confiez l’exécution des tests à votre CI habituelle, c’est-à-dire aux vérifications automatisées qui s’appliquent aux modifications proposées.

Enregistrez ce fichier sous .github/workflows/claude.yml. Les références actions/checkout@v6 et anthropics/claude-code-action@v1 figurent dans l’exemple actuel d’Anthropic. Le plafond de cinq tours et le délai maximal de quinze minutes sont des choix de départ, pas les valeurs par défaut d’Anthropic. Workflow officiel.

name: Claude on request
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    timeout-minutes: 15
    concurrency:
      group: claude-small-team
      cancel-in-progress: false
    permissions:
      contents: write
      issues: write
      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 }}
          use_commit_signing: true
          claude_args: |
            --max-turns 5
            --tools "Read,Glob,Grep,Edit,Write"
            --disallowedTools "Bash,WebFetch,WebSearch"

Pour utiliser la facturation par abonnement, remplacez la ligne anthropic_api_key par claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}. Ne renseignez qu’un seul mode. Conservez id-token: write, requis par l’authentification par défaut de la GitHub App. Workflow officiel et authentification, référence des paramètres.

Chaque réglage a un rôle différent :

• --tools sélectionne les outils intégrés que Claude peut utiliser. Read, Glob et Grep inspectent les fichiers ; Edit et Write les modifient. Ce réglage ne limite pas les outils MCP, ces outils connectés séparément que l’action utilise pour communiquer avec GitHub.
• --allowedTools autorise l’utilisation des outils nommés sans demande de permission. Ce n’est pas une liste exhaustive des outils accessibles. Ici, la ligne explicite --disallowedTools interdit les outils shell et web.
• --max-turns limite les itérations de travail de l’agent. Ce réglage ne plafonne ni les tokens ni les dépenses en dollars. Atteindre cette limite peut terminer l’exécution sur une erreur, avec un travail inachevé. Référence de la CLI.

use_commit_signing: true fait passer les commits par l’API GitHub. C’est ce qui permet à ce profil d’enregistrer les modifications sans donner à Claude accès aux commandes git via un shell. Aucun secret de signature supplémentaire n’est nécessaire. Les outils GitHub de l’action restent disponibles : ce profil conserve donc la capacité d’écrire. Signature des commits, implémentation de l’action.

Le groupe de concurrence fixe autorise une seule tâche de ce workflow à s’exécuter à la fois par dépôt. Avec le comportement par défaut de la file d’attente, une nouvelle demande en attente peut en remplacer une plus ancienne : ce n’est pas une file de tâches durable. Le délai maximal borne la durée totale de la tâche, préparation comprise. Gestion de la concurrence dans GitHub, syntaxe des workflows.

Essayez @claude review this PR for missing permission checks; report findings without changing files. Pour une issue, essayez @claude fix the null handling described above, change only the parser and its regression test, and state which checks were not run.

Par défaut, la personne qui déclenche l’action doit avoir un accès en écriture au dépôt, et les bots sont bloqués. Pour la correction d’une issue, attendez-vous à obtenir une branche et un lien permettant à un humain de créer la PR. Précisez cette distinction dans les consignes de votre équipe. Sécurité de l’action.

Passez à la revue de code automatique après l’essai

Pour lancer automatiquement les revues de PR, sélectionnez le workflow de revue pendant l’installation avec /install-github-app. Son plugin de revue de code utilise --comment et l’autorisation de l’outil de commentaire ci-dessous pour publier ses observations. Exemple officiel de revue.

Dans ce workflow de revue distinct, les paramètres de l’action comprennent :

plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
plugins: "code-review@claude-code-plugins"
prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
claude_args: >-
  --max-turns 5
  --allowedTools "mcp__github_inline_comment__create_inline_comment"

Utilisez ces paramètres dans le workflow officiel pull_request, pas dans le workflow à mentions présenté plus haut. Conservez ses étapes de récupération du code et d’authentification ainsi que les permissions de la tâche. Ajoutez un délai maximal et excluez les PR issues de forks avec if: github.event.pull_request.head.repo.full_name == github.repository. Considérez le plafond de tours comme un réglage d’essai : une revue qui épuise ses tours reste incomplète. Le skill de revue documenté ignore également certaines PR, notamment les brouillons.

Distinguez le périmètre de l’installation de celui des outils

Commencez par une installation sur une sélection de dépôts. L’application officielle Claude partage ses permissions entre plusieurs fonctionnalités de Claude, et GitHub ne permet pas de n’en accepter qu’une partie. Un bloc YAML permissions restreint ne réduit pas les droits accordés à l’application lors de son installation. Modèle de permissions de l’application.

Si ce périmètre est trop large, optez pour une application personnalisée avec des accès Contents, Issues et Pull requests. Cette configuration ajoute les secrets APP_ID et APP_PRIVATE_KEY, ainsi qu’une étape qui crée un jeton d’application et le transmet via github_token. Pour les équipes prêtes à supprimer les clés API Claude statiques, le guide d’installation documente aussi la fédération d’identité des charges de travail : l’identité de la tâche GitHub est échangée contre un accès API de courte durée. Configuration de l’application personnalisée et de la fédération.

Ajoutez un fichier CLAUDE.md concis qui précise les priorités de revue, les zones où les modifications sont permises et les éléments de preuve attendus pour un correctif. Les consignes orientent le travail ; les permissions du dépôt et les restrictions sur les outils imposent les limites d’accès. Avant d’activer les exécutions sans supervision, examinez les hooks configurés, ces commandes lancées automatiquement lors des événements du cycle de vie, ainsi que les éventuels serveurs d’outils supplémentaires. Consignes du projet. Notre test de Claude Code aide à décider plus largement si l’outil convient à vos besoins, et le guide des commandes slash explique les commandes utilisées pendant l’installation.

Six tâches à lui confier, par ordre de priorité

Commencez par les demandes faciles à formuler et les résultats faciles à vérifier. Les workflows suivants sont des pistes d’utilisation, pas des gains mesurés ni des garanties.

Le profil de départ ne peut ni installer de dépendances ni exécuter une suite de tests. Si la tâche l’exige, ajoutez un profil d’exécution examiné séparément, réservé au code de confiance, avec des autorisations de commandes précises et ses propres limites. Une commande de test autorisée exécute tout de même le code du dépôt ; son nom rassurant ne rend pas ce code sûr.

Réglez ces problèmes avant de multiplier les déclencheurs

Les PR provenant de forks peuvent ne pas avoir accès aux secrets. GitHub ne transmet normalement pas les secrets aux exécutions pull_request et pull_request_review_comment déclenchées depuis un fork. L’absence d’identifiant Claude dans ces tâches traduit une frontière de confiance. Ne passez pas à pull_request_target en exécutant le code du fork simplement pour obtenir les secrets. Une tâche issue_comment déclenchée par un responsable du dépôt peut elle aussi disposer des secrets : faire confiance à l’auteur du commentaire ne suffit donc pas à rendre les fichiers de la PR fiables. Recommandations de GitHub sur la sécurité des forks.

Limiter les outils ne neutralise pas le code lancé au démarrage du projet. L’action restaure certains éléments de configuration de Claude depuis la branche de base, mais les scripts et d’autres fichiers du projet peuvent toujours provenir de la PR. Auditez les hooks et la configuration des serveurs d’outils, en plus des outils autorisés à Claude. Frontières de confiance de l’action.

Le temps de runner reste une contrainte distincte. Les runners standard hébergés par GitHub sont gratuits pour les dépôts publics. Les dépôts privés disposent de quotas inclus dans leur offre, puis de dépassements payants ; l’épuisement des quotas sans moyen de paiement peut arrêter les tâches. Consultez la page d’utilisation d’Actions en parallèle de celle de Claude. Facturation de GitHub Actions.

Les limites de débit peuvent interrompre un workflow valide. Les limites API portent sur le nombre de requêtes et de tokens d’entrée et de sortie par minute, les tokens étant les fragments de texte traités par le modèle. Face à une erreur 429 accompagnée de retry-after, attendez avant de réessayer et réduisez le nombre de tâches simultanées. Une erreur 429 liée au plafond de dépenses du palier, sans cet en-tête, demande de régler la facturation ou la limite concernée, pas de relancer en boucle. L’authentification par abonnement reste soumise aux limites d’utilisation de l’offre. Limites de débit de l’API, limites d’utilisation de Claude.

Un bot silencieux et une CI qui ne démarre pas sont deux problèmes différents. Si le bot ne répond pas, vérifiez que le workflow existe sur la branche par défaut, qu’Actions est activé, que le secret correspond au paramètre utilisé et que l’auteur du commentaire dispose d’un accès en écriture. Utilisez la mention complète @claude. Si la CI ne se déclenche pas ensuite, vérifiez si quelqu’un a remplacé l’authentification de l’application par github_token: ${{ secrets.GITHUB_TOKEN }} : GitHub bloque de nombreux événements créés par ce jeton, et certains workflows de PR nécessitent une approbation. Comportement du jeton GitHub.

Deux offres à construire autour de ce workflow

La piste la plus solide est un service de revue géré pour les petites équipes. Le client visé est un responsable technique qui veut des observations utiles, des responsabilités claires et des limites de fonctionnement prévisibles. Les estimations DataForSEO pour les recherches en anglais aux États-Unis, récupérées le 15 octobre 2026, donnent 1,300 recherches mensuelles pour « ai code review ». C’est un signe d’intérêt, pas un nombre de clients. Une première offre commercialisable pourrait configurer un dépôt, formaliser ses priorités de revue, évaluer les observations sur d’anciennes PR et fournir un suivi de l’utilisation et des échecs. La difficulté, c’est la lassitude face aux faux positifs : le travail durable consiste à préserver la qualité des revues à mesure que le code évolue. Une simple interface autour d’un prompt générique donne peu de raisons de rester.

Une agence pourrait acheter un ensemble réutilisable de règles de revue pour ses dépôts clients. DataForSEO estime à 590 recherches mensuelles le volume de « ai code review tools » et à 140 celui de « github ai code review » sur le même marché. Le produit minimal pourrait réunir un workflow réutilisable, des modèles de consignes propres à chaque client, un registre des responsables des identifiants et des vérifications signalant les limites manquantes. Il pourrait aider une agence à conserver des configurations cohérentes lors des passations. La difficulté tient aux différences de permissions et d’environnements de test entre clients : un modèle doit être entretenu et évalué pour rester utile. Les publics de ces requêtes se recoupent ; n’additionnez donc pas leurs volumes pour en déduire la taille du marché.

Choisissez l’environnement adapté à la tâche

Choisissez GitHub Actions quand le travail dépend d’un événement du dépôt et que votre équipe veut gérer la configuration, les permissions et les journaux avec sa CI. Choisissez une session cloud pour une tâche ponctuelle à lancer et à piloter depuis un navigateur, même lorsque votre ordinateur est fermé. Choisissez une routine planifiée pour une tâche récurrente enregistrée, comme une vérification nocturne du backlog, si vous préférez la planification et la configuration hébergées de Claude à la maintenance d’un workflow YAML. Les routines acceptent aussi les déclencheurs GitHub et API : le besoin de planification n’impose donc pas Actions. Elles restent en préversion de recherche. Sessions cloud, routines.

Lundi, demandez à l’administrateur du dépôt d’installer l’application et de fusionner le workflow restreint. Soumettez-lui un bug connu et une demande de revue ciblée, puis comparez ses résultats au jugement de l’équipe. N’élargissez les déclencheurs que lorsque ces résultats justifient l’attention et la consommation nécessaires.

Pour faire mettre en place et maintenir ce workflow dans votre équipe, faites-vous accompagner en automatisation par IA.