GitHub Actions et revue de code

La voie gérée : Code Review

L'option la plus simple est Code Review. Il s'agit d'un service hébergé par Anthropic qui examine vos pull requests via l'application Claude GitHub. Vous n'avez rien à construire ni à héberger. Vous l'activez, et il commence à publier des observations sous forme de commentaires en ligne, directement sur les lignes concernées.

Un Owner de votre organisation Claude l'active depuis les paramètres d'administration de Claude Code. Vous trouverez une section Code review avec un interrupteur Allow code review qui lance la configuration.

À partir de là, l'Owner installe l'application Claude GitHub, choisit les dépôts qu'elle surveille, et décide quand elle s'exécute. Si l'Owner n'est pas également propriétaire de l'organisation GitHub, quelqu'un doit d'abord installer et lier l'application. Vous avez plusieurs options de déclenchement :

• Une fois à l'ouverture d'une PR
• À chaque push sur la PR
• Uniquement lorsque quelqu'un commente @claude review

Une fois activé, tout s'exécute sur l'infrastructure d'Anthropic. Un ensemble d'agents de revue analyse le diff par rapport à l'intégralité de votre base de code, et non seulement les lignes modifiées isolément. Il publie ensuite les observations sous forme de commentaires en ligne sur les lignes concernées, classées par gravité, avec un tableau récapitulatif dans le check run.

Voici à quoi ressemble l'une de ces observations. Elle apparaît comme un commentaire de Claude, directement sur la ligne, avec une explication claire et une correction suggérée.

Ce qui est pratique, c'est qu'il déduplique et classe les observations. Ainsi, au lieu d'un mur de remarques mineures, vous lisez une poignée de problèmes réels qui méritent votre attention.

Ce que Code Review fait et ne fait pas

Quelques points à garder à l'esprit concernant les limites de ce service :

• Il n'approuve ni ne bloque jamais la PR. La décision finale reste entre les mains d'un humain. Claude signale les problèmes ; c'est à vous de décider.
• Il ne pousse pas de corrections. Le service se contente de publier des observations.
• Il est disponible sur les forfaits Team et Enterprise.

Comme le service se contente de publier des observations, c'est à vous d'agir : corrigez le code et poussez-le. Pour vérifier votre correction avant de la pousser, exécutez /code-review depuis votre propre terminal. Il effectue sa propre revue de votre diff, et son option --fix applique les observations de cette revue à votre arborescence de travail.

La voie artisanale : la GitHub Action

Code Review gère la revue. Lorsque la tâche va au-delà de la revue, vous vous tournez vers la GitHub Action. Elle est destinée à l'intégration continue personnalisée : implémenter des changements à partir d'un commentaire, exécuter des rapports planifiés, tout ce pour quoi vous écririez normalement un workflow. Elle exécute l'agent sur les commentaires de PR, les tâches planifiées et tout événement GitHub.

La configuration commence dans Claude Code. Exécutez la commande /install-github-app. Vous aurez besoin des droits d'administration sur le dépôt pour cela. La commande slash vous guide à travers l'installation de l'application GitHub et la configuration du secret de clé API Anthropic sur le dépôt.

L'action elle-même est anthropics/claude-code-action@v1. Voici les entrées que vous utiliserez réellement :

• anthropic_api_key — requis lorsque l'exécution appelle la Claude API, sauf si vous vous authentifiez avec claude_code_oauth_token (issu d'un abonnement Claude) ou avec la fédération d'identité de charge de travail (configurée via un compte de service Claude Console, donc sans secret stocké). Non utilisé avec les fournisseurs cloud ci-dessous.
• github_token — facultatif. Omettez-le et l'action s'authentifie en tant qu'application Claude GitHub que vous avez installée lors de la configuration. Ne transmettez un jeton que pour remplacer ce comportement.
• trigger_phrase — ce que l'action recherche dans les commentaires. Par défaut, @claude.
• use_bedrock / use_vertex / use_foundry — acheminent l'exécution via Amazon Bedrock, Google Cloud's Agent Platform ou Microsoft Foundry au lieu de la Claude API, en vous connectant avec votre compte cloud plutôt qu'avec une clé API.
• prompt — l'instruction pour une exécution automatisée. Définissez-la et Claude s'exécute sur l'événement sans attendre une mention. Omettez-la et l'action attend la phrase de déclenchement.
• claude_args — une chaîne d'arguments CLI transmise directement à Claude Code.

Un workflow qui répond à @claude

Déposez un workflow dans .github/workflows/claude.yaml et il écoute @claude dans les commentaires de PR et les commentaires d'issues. Sous les permissions du job, accordez id-token: write afin que l'action puisse se connecter en tant qu'application Claude GitHub. L'étape principale ressemble à ceci :

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    trigger_phrase: "@claude"
    claude_args: "--max-turns 5 --model claude-sonnet-5"

Maintenant, quelqu'un écrit @claude implement the spec in the linked Linear issue sur une pull request, et l'action le prend en charge. Claude pousse des commits et publie des commentaires décrivant ce qu'il a fait.

Un workflow qui s'exécute selon une planification

La même action fonctionne pour un récapitulatif quotidien. Un déclencheur cron se déclenche, disons à 9h00 UTC, l'action exécute votre prompt, et vous lisez le récapitulatif dans le journal de cette exécution. Une exécution planifiée ne publie pas de commentaire d'elle-même. Vous pouvez également ajouter un déclencheur workflow_dispatch pour pouvoir la lancer manuellement depuis l'onglet Actions.

Lorsque l'action s'exécute, vous pouvez suivre son déroulement étape par étape dans l'onglet Actions, comme pour tout autre workflow GitHub.

Ajuster l'exécution avec claude_args

La ligne claude_args est l'endroit où se fait l'ajustement fin. Quelques réglages à connaître :

• --max-turns 5 impose une limite stricte sur la boucle de l'agent, afin qu'elle ne puisse pas tourner indéfiniment.
• Le mode de permission. Pour une tâche non supervisée, vous voudrez qu'elle ne s'arrête pas pour demander, puisqu'il n'y a personne pour répondre.
• Les outils autorisés. Donnez à la tâche exactement ce dont elle a besoin, rien de plus. Pour un rapport, cela signifie un accès en lecture seule.

Lequel utiliser ?

Voici la version courte :

• Pour les revues de PR, optez pour la voie gérée. Activez Code Review, laissez l'application GitHub publier des observations en ligne, puis corrigez le code et poussez-le.
• Tournez-vous vers l'action lorsque la tâche va au-delà de la revue. Utilisez /install-github-app pour la configuration, un workflow pour les mentions @claude, un autre pour le cron, et tout l'ajustement fin se fait dans claude_args.

Commencez par le service géré. Passez à l'action dès que vous avez besoin que Claude fasse réellement quelque chose dans l'intégration continue, pas seulement qu'il commente.