GitHub Actions : mentionnez @claude dans une PR et laissez-le travailler en autonomie

📚 Navigation de la série : L'article précédent 43 Flux de travail Git vous a montré comment laisser Claude gérer vos branches, rédiger vos commits et ouvrir vos PR en local — tout cela se faisait avec vous devant votre ordinateur, Claude travaillant à vos côtés. Cet article vous montre comment le porter sur le cloud : une fois configuré, il vous suffit de saisir @claude dans un ticket (issue) ou une PR sur GitHub pour qu'il s'exécute de lui-même pour analyser le code, faire des modifications et ouvrir une PR, sans que vous ayez à ouvrir votre ordinateur. C'est le principe de Claude Code GitHub Actions (la plateforme d'automatisation des flux de travail de GitHub).

Imaginez ce scénario vers 23 heures : vous êtes déjà couché et un message apparaît sur le groupe de l'équipe.

Un collègue : « Tu as regardé la PR de X ? Elle est bloquée depuis ce matin, et on doit mettre en production demain. » Vous : « Je dors, je regarde ça demain matin. » Lui : « ... Demain matin, ce sera trop tard. »

Dans ce genre de situation, si vous aviez déjà configuré Claude Code GitHub Actions sur ce dépôt, vous vous épargneriez bien des nuits blanches : avant même votre réveil, une revue de code (review) générée automatiquement par Claude serait déjà publiée dans les commentaires de la PR, signalant ligne par ligne un risque de pointeur nul (null pointer) et deux cas limites non gérés. Votre collègue n'aurait plus qu'à appliquer les corrections et à fusionner la PR.

En résumé, le fonctionnement de Claude Code décrit dans les quarante articles précédents nécessitait votre présence physique, un terminal ouvert et votre supervision active. Cet article sur GitHub Actions aborde un autre cas de figure : l'affranchir de votre ordinateur pour l'installer directement sur les serveurs de GitHub, où une simple mention @claude suffit à le mobiliser. Que vous soyez en déplacement, endormi ou en réunion, il continue à prendre en charge les tickets (issues), relire les PR ou corriger des bugs.

À la fin de cet article, vous obtiendrez :

• Une explication simple de ce qu'est Claude Code GitHub Actions et de sa relation avec la version locale de Claude Code.
• Le fonctionnement détaillé de la mention @claude : où la saisir et comment l'agent décide ou non de répondre.
• Le fichier workflow YAML minimal nécessaire avec l'explication de chaque ligne, prêt à être copié et utilisé.
• Trois cas d'usage indispensables : la revue de code automatique, la modification automatique basée sur un ticket, et les tâches planifiées.
• Comment configurez votre clé API (API key) de manière sécurisée dans GitHub, et la ligne rouge absolue à ne pas franchir.
• Un cas pratique pas à pas avec le résultat attendu : installer et valider la configuration sur votre propre dépôt en 5 minutes.

---

01 D'abord, comprendre : c'est « Claude Code installé dans GitHub »

Commençons par la conclusion : la version GitHub Actions de Claude Code consiste à exécuter la même logique que votre version locale de Claude Code, mais sur les serveurs de GitHub. Elle n'est plus déclenchée par une commande dans votre terminal, mais par des événements du dépôt (ouverture de PR, nouveau commentaire, planification horaire).

Si vous vous remémorez les quarante articles précédents, vous utilisiez Claude Code ainsi : vous ouvriez un terminal sur votre machine, lanciez claude, puis dialoguiez avec lui pendant qu'il modifiait vos fichiers. Son fonctionnement reposait sur votre présence active : vous deviez garder votre machine allumée, le surveiller et valider ses actions au fur et à mesure.

GitHub Actions supprime cette contrainte. Sa définition officielle est limpide :

Claude Code GitHub Actions 为您的 GitHub 工作流带来了 AI 驱动的自动化。只需在任何 PR 或 issue 中简单地提及 @claude，Claude 就可以分析您的代码、创建拉取请求、实现功能和修复错误——所有这些都遵循您项目的标准。

Analogie : recruter un collègue d'astreinte de nuit qui ne dort jamais. Pendant la journée, les membres de votre équipe supervisent le code, mais la nuit, le poste est vacant. Imaginez que vous recrutiez un collaborateur de nuit : il ne badge pas, n'a pas besoin de bureau ni de salaire fixe (vous payez uniquement à l'usage). Dès que quelqu'un l'interpelle dans la discussion avec un « @claude, analyse cette PR s'il te plaît » ou « @claude, corrige ce bug », il se met au travail et publie le résultat à son retour. Vous pouvez dormir tranquille pendant qu'il travaille. Claude dans sa version GitHub Actions est ce collaborateur de nuit, installé dans les centres de données de GitHub.

Il y a un point crucial à ne pas confondre : ce n'est pas un nouveau produit distinct, le moteur sous-jacent reste Claude Code. La documentation précise qu'il s'appuie sur le SDK Claude Agent (que nous aborderons à l'article 45) et qu'il continue de lire le fichier CLAUDE.md à la racine de votre dépôt (votre « guide de référence du projet » détaillé à l'article 18). Par conséquent, les conventions, styles et règles que vous avez définis pour votre projet sont pleinement respectés par ce collaborateur virtuel, selon les mêmes standards que votre outil local.

En pratique, une fois configuré, vous pourrez :

• PR 开出来了，没人有空 review——让它自动审一遍，逐行标出问题
• issue 描述清楚了，但你没空写代码——评论一句 @claude 把这个实现了，它直接开个 PR 把功能实现了
• CI 挂了，半夜没人管——让它分析报错、尝试修复

💡 Résumé en une phrase : La version GitHub Actions de Claude Code est un agent déporté sur les serveurs de GitHub, piloté par les événements du dépôt ; il travaille de manière autonome en respectant votre fichier CLAUDE.md et les normes de votre projet, à l'image d'un collaborateur d'astreinte nocturne.

---

02 La mention @claude : comment l'interpeller et comment il détecte les requêtes

L'usage principal consiste à mentionner l'agent avec @ dans un commentaire de ticket (issue) ou de PR pour déclencher son exécution. Analysons ce mécanisme : où écrire la mention, sa syntaxe et le processus de détection.

Analogie : mentionner un collègue d'astreinte dans un canal de discussion pour lui attribuer une tâche. Dans un canal d'équipe encombré de messages, si vous mentionnez spécifiquement le collègue de permanence en précisant la consigne, il comprend immédiatement que la demande lui est adressée et s'en charge. C'est exactement ainsi que fonctionne la mention @claude : l'agent reste silencieux et ignore les échanges ordinaires, mais dès qu'il is mentionné avec @, il traite le commentaire comme une tâche qui lui est directement assignée.

Où pouvez-vous utiliser cette mention ? La documentation liste plusieurs emplacements usuels de votre quotidien de développement :

• PR 的评论区（issue comment）
• PR 代码行上的 review 评论（pull request review comment）
• issue 的正文或评论

Que saisir dans le message ? Formulez votre demande avec des mots simples et précis, comme vous le feriez avec un collègue. Par exemple :

@claude 按这个 issue 的描述把功能实现了
@claude 这个接口的用户认证该怎么做
@claude 把用户面板组件里那个 TypeError 修了

qui signifient respectivement « implémente la fonctionnalité conformément à la description de ce ticket », « comment implémenter l'authentification des utilisateurs pour cette API » et « corrige l'erreur TypeError dans le composant du panneau utilisateur ». L'agent va automatiquement analyser le contexte (lire le ticket, inspecter le code associé, consulter le fichier CLAUDE.md) puis apporter la réponse appropriée : soumettre une PR s'il s'agit de modifications de code, ou répondre sous forme de texte s'il s'agit d'une question.

Cela fait écho à la règle d'or de l'article 15 : plus vos instructions sont précises, plus le résultat sera pertinent. Demander à un collaborateur « jette un œil à cette PR » produit un résultat très différent de « vérifie la sécurité des accès concurrents et l'absence d'injections SQL sur cette PR ». Il en va de même pour @claude : une consigne vague comme « vérifie » donnera lieu à une relecture superficielle, tandis qu'une consigne ciblée comme « recherche les vulnérabilités d'injection SQL » orientera son travail avec précision.

Il y a un piège classique pour les débutants, documenté explicitement dans le guide de dépannage :

确认评论包含 @claude（不是 /claude）。

C'est une erreur fréquente : après avoir configuré le système, on saisit joyeusement /claude review this dans la PR, puis on attend cinq minutes sans obtenir de réponse, pensant à une erreur de clé API. On réalise finalement qu'on a confondu l'arobase @ avec la barre oblique /. En effet, /claude est la syntaxe des commandes du terminal local (présentée à l'article 36), qui n'a aucune signification dans un commentaire GitHub. L'activation sur le cloud repose sur la mention @claude (arobase), et non sur une barre oblique. Garder ce détail en tête vous évitera de longues séances de débogage inutiles.

Caractéristique	Terminal local (articles 1 à 43)	GitHub Actions (cet article)
Déclencheur	Lancement manuel via la commande claude	仓库事件（评论、开 PR、定时）
Commande	Saisie directe, commandes / (barre oblique)	评论里 @claude（@ 符号！）
Supervision humaine	Requise tout au long de la session	不用，它在云端自己跑
Environnement	Machine locale de l'utilisateur	GitHub 托管的 runner
Approbation des actions	Validation manuelle étape par étape	按 workflow 预设的权限，无人值守

💡 Résumé en une phrase : Saisir @claude suivi d'une consigne précise dans un commentaire de ticket ou de PR lance son exécution ; l'agent étudie alors le contexte et le fichier CLAUDE.md. Attention à ne pas utiliser de barre oblique (/claude), seule la mention arobase est reconnue sur le cloud.

---

03 Installation : la méthode simplifiée par commande automatisée

Pour que la mention @claude fonctionne, vous devez installer les trois composants requis sur votre dépôt : une application GitHub (pour autoriser l'accès en lecture/écriture de Claude), une variable secrète (votre clé API) et un fichier workflow (pour définir les conditions de déclenchement de Claude par GitHub).

Bien que cela puisse sembler complexe, l'éditeur propose une méthode d'installation rapide en une seule commande. Le moyen le plus simple consiste à exécuter la commande suivante dans votre terminal Claude Code local :

/install-github-app

Remarque : cette commande /install-github-app doit être saisie dans votre session claude locale (il s'agit bien d'une commande du terminal local comme vu à l'article 36, à ne pas confondre avec la mention @claude sur le cloud détaillée précédemment). Elle lance un assistant interactif qui effectue les actions suivantes :

此命令将指导您完成 GitHub 应用和所需密钥的设置。

Concrètement, l'assistant gère l'installation de l'application GitHub, la configuration de la variable ANTHROPIC_API_KEY dans les secrets du dépôt, et l'enregistrement d'un fichier de workflow d'exemple dans le répertoire .github/workflows/. Il vous suffit de suivre les instructions à l'écran.

Deux prérequis indispensables doivent toutefois être respectés, comme le souligne un encadré de la documentation :

• 您必须是仓库管理员才能安装 GitHub 应用并添加密钥
• 此快速启动方法仅适用于直接 Claude API 用户。如果您使用 Amazon Bedrock 或 Google Vertex AI，请参阅相应部分。

En clair : premièrement, vous devez disposer des droits d'administration sur le dépôt pour ajouter l'application et les clés secrètes — il s'agit d'une exigence de sécurité de GitHub, et non d'une limitation de l'agent. Deuxièmement, cet assistant rapide est réservé aux clients utilisant l'API Anthropic directe ; si votre organisation s'appuie sur AWS Bedrock ou Google Vertex AI (comme évoqué à l'article 05 pour les infrastructures tierces), une configuration manuelle est nécessaire.

Quels sont les droits requis par l'application GitHub ? La documentation liste trois permissions d'accès en lecture/écriture :

• Contents：读写（用来改仓库文件）
• Issues：读写（用来响应 issue）
• Pull requests：读写（用来创建 PR 和推送更改）

Analogie : attribuer des droits d'accès sur le badge de votre collaborateur de nuit. Ces trois permissions représentent les accès programmés sur son badge : l'accès au « code source » pour travailler sur les fichiers, à l'« espace des tickets » pour échanger, et à l'« espace des PR » pour soumettre ses contributions. Sans badge, il reste bloqué à l'entrée ; lui accorder trop d'accès poserait un risque de sécurité. Ces three habilitations constituent le strict minimum requis pour son travail.

Si la commande /install-github-app échoue (pour des raisons de réseau ou de droits), vous pouvez effectuer la procédure manuellement : installez l'application depuis https://github.com/apps/claude, configurez le secret dans les paramètres du dépôt, et copiez le fichier YAML d'exemple disponible sur le dépôt officiel examples/claude.yml. Privilégiez toutefois la commande automatisée : la configuration manuelle est bien plus fastidieuse, notamment pour retrouver et copier le bon fichier d'exemple.

这套东西需要访问 GitHub 和 Claude 的服务器，国内网络如果不通，装 App、跑 workflow 那几步可能卡住，先开「魔法上网」再试。

💡 Résumé en une phrase : La méthode d'installation recommandée consiste à exécuter /install-github-app dans votre session locale pour configurer l'application, les secrets et le workflow. Vous devez disposer des droits d'administration et utiliser l'API Anthropic directe ; les permissions demandées sont limitées aux accès en lecture/écriture sur Contents, Issues et Pull requests.

---

04 Le workflow YAML : le planning d'affectation de l'agent

Une fois l'installation effectuée, les conditions de mobilisation de Claude sont définies dans le fichier de workflow — un document au format YAML situé dans le répertoire .github/workflows/. Analisons en détail un exemple de workflow minimal.

Analogie : le planning de présence de votre collaborateur de nuit. Le fichier de workflow fait office de planning, stipulant deux éléments : quand il doit prendre son service (les déclencheurs) et ses tâches durant son temps de présence (les étapes d'exécutions). Sans planning, votre collaborateur ne sait ni quand commencer ni quoi faire.

Voici le workflow minimal proposé pour réagir aux mentions @claude dans les commentaires :

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          # Responds to @claude mentions in comments

Ce fichier comporte quatre sections principales simples à appréhender :

1. La clé name : Le nom du workflow, libre, qui apparaîtra dans l'interface GitHub Actions.

2. La clé on (les conditions de déclenchement) : Spécifie quand le workflow s'exécute. Ici, le déclenchement se produit lors de l'ajout d'un commentaire sur un ticket (issue_comment de type created) ou sur une ligne de code d'une PR (pull_request_review_comment de type created). Toute nouvelle publication de commentaire active le workflow.

3. La section jobs (les tâches à exécuter) : Définit une tâche nommée claude exécutée sur runs-on: ubuntu-latest (une machine virtuelle Ubuntu fournie par GitHub). Vos fichiers sources restent confinés dans l'environnement d'exécution sécurisé de GitHub.

4. La section steps (les étapes de traitement) : Comporte l'action officielle uses: anthropics/claude-code-action@v1 d'Anthropic (version v1). Les paramètres with lui transmettent la clé secrète ANTHROPIC_API_KEY (voir section suivante). La ligne commentée indique que l'action réagit aux mentions de l'arobase.

L'intérêt majeur de cette version est que le fichier ne contient aucun filtre de texte pour isoler la chaîne « @claude ». Cette détection est gérée en arrière-plan. La documentation précise :

该 action 现在根据您的配置自动检测是在交互模式（响应 @claude 提及）还是自动化模式（立即使用提示运行）下运行。

Autrement dit : si vous renseignez le paramètre prompt, l'action passe en « mode automatisé » et s'exécute dès le déclenchement (comme pour la revue de code présentée ci-après) ; si vous omettez prompt, elle passe en « mode interactif » et attend d'être interpellée par @claude. Notre exemple minimal n'ayant pas de paramètre prompt, il s'exécutera uniquement si l'arobase est présente dans le commentaire.

⚠️ 这是从 beta 版升级过来的人最容易翻车的地方。老版本要手动写 mode: "tag"，还要用 direct_prompt；v1 把这些全砍了——mode 删掉（自动检测）、direct_prompt 改叫 prompt。如果你在网上抄到带 @beta、mode:、direct_prompt 的老配置，直接换成 v1 写法，别照抄。

Où déclarer les arguments du CLI tels que --max-turns ou --model ? L'action propose le paramètre claude_args : la plupart des options disponibles dans l'outil local peuvent y être insérées :

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    prompt: "Your instructions here"          # 可选：给它的指令
    claude_args: "--max-turns 5 --model claude-sonnet-4-6"  # 可选：CLI 参数

Voici les options d'arguments les plus courantes référencées :

参数	干什么	默认
--max-turns	最多来回几轮（防它没完没了烧钱）	10
--model	用哪个模型（如 claude-opus-4-8）	默认 Sonnet
--allowedTools	允许用哪些工具（逗号分隔）	—
--mcp-config	MCP 配置文件路径（第 22 篇那套）	—
--debug	开调试输出，排错时用	关

Claude Code GitHub Actions s'appuie sur le modèle Sonnet par défaut ; pour utiliser Opus 4.8, vous devez le déclarer explicitement via --model claude-opus-4-8 dans claude_args. Sonnet est amplement suffisant pour les revues de code courantes ou les corrections légères ; réservez Opus pour les refactorisations complexes ou les tâches de haut niveau (la logique de sélection de modèle vue à l'article 30 reste pleinement applicable ici).

💡 Résumé en une phrase : Le workflow constitue le planning de l'agent — la clé on définit les déclencheurs, et steps appelle l'action officielle. La version v1 identifie automatiquement le mode (exécution immédiate si un prompt est fourni, attente de mention @claude dans le cas contraire). Les options du CLI se déclarent dans claude_args.

---

05 Trois cas d'usage concrets : revue automatique, correctif guidé et tâches planifiées

Dépassons le cadre de la simple réaction aux mentions. Voici trois exemples de workflows prêts à l'emploi répondant aux besoins de production les plus fréquents. Le rôle et la structure de chaque configuration y sont détaillés.

Cas d'usage 1 : Revue de code automatique à chaque PR (sans mention, automatique)

L'analyse démarre d'elle-même dès qu'une PR est créée ou mise à jour, sans intervention humaine.

name: Code Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Review this pull request for code quality, correctness, and security."
          claude_args: "--max-turns 5"

Par rapport au modèle minimal, deux différences majeures apparaissent : les déclencheurs ciblent l'événement pull_request sur les actions opened (PR créée) et synchronize (nouveau commit poussé), et le paramètre prompt est renseigné. Comme vu précédemment, la présence de prompt active le « mode automatisé » : dès son déclenchement, l'agent réalise une revue axée sur la qualité, la conformité et la sécurité, sans attendre de mention. Chaque publication de code est ainsi passée au crible de manière autonome.

Si vous préférez une solution de relecture gérée de bout en bout sans écrire de fichier de workflow, Anthropic propose un service managé de Code Review (réservé aux abonnements Team/Enterprise) ; une fois activé, il analyse chaque PR, classe les anomalies par gravité et accepte les personnalisations via un fichier REVIEW.md. Notre article se concentre sur l'intégration dans votre propre CI, ce service managé étant mentionné pour information.

Cas d'usage 2 : Modification de code pilotée par ticket (déclenchement par mention)

Ce cas utilise la structure minimale réagissant aux mentions. La pertinence du résultat dépend de la formulation de votre consigne dans le fil du ticket :

@claude 按这个 issue 的描述把功能实现了

Claude analyse la description du ticket, examine le code et le fichier CLAUDE.md, puis implémente la fonctionnalité sur une nouvelle branche avant d'ouvrir une PR pour relecture. J'ai personnellement configuré une fonction d'exportation CSV sur un outil interne de cette manière : après avoir spécifié les colonnes et le format requis dans le ticket, j'ai mentionné l'agent ; une vingtaine de minutes plus tard, la PR était disponible. Le développement s'est fait sans ouvrir une seule fois mon éditeur de code.

La résolution de bugs suit la même approche :

@claude 把用户面板组件里那个 TypeError 修了

L'agent localise l'anomalie, la corrige, et met à jour la branche ou crée une PR.

Cas d'usage 3 : Exécution planifiée (déclenchement à heure fixe)

Ce workflow s'affranchit des événements interactifs pour s'exécuter à heure fixe (par exemple, pour dresser chaque matin à 9h la synthèse des commits et des tickets ouverts de la veille).

name: Daily Report
on:
  schedule:
    - cron: "0 9 * * *"
jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Generate a summary of yesterday's commits and open issues"
          claude_args: "--model opus"

L'instruction on: schedule avec un paramètre cron: "0 9 * * *" planifie une exécution quotidienne à 9h00 (UTC) ; le script traite alors la requête fournie dans prompt. Ces tâches régulières d'arrière-plan gagnent à être déléguées à votre agent virtuel.

Comparatif rapide des trois modes d'exécution :

Cas d'usage	Déclencheur	Prompt fourni	Mode active	Scénario classique
Revue automatique	Événement pull_request (création/mise à jour)	Oui	Automatisé	Relecture systématique à chaque contribution
Correctif par ticket	Commentaire de ticket (mention @claude)	Non	Interactif	Traduction d'anomalie en code, correction
Tâche planifiée	Planificateur schedule (syntaxe cron)	Oui	Automatisé	Rapports d'activité, analyses régulières

Retenez la règle fondamentale commune : déclarer un prompt active l'exécution automatisée immédiate ; l'omettre configure l'attente d'une mention @claude. Le choix dépend du comportement souhaité.

💡 Résumé en une phrase : Les trois architectures types sont la revue automatique de PR (avec prompt), la correction sur ticket (sans prompt, par mention) et la planification temporelle (cron avec prompt). Elles reposent toutes sur la combinaison d'un événement déclencheur et de la présence ou de l'absence du paramètre prompt.

---

06 Sécurité des identifiants : la ligne rouge absolue

Vous aurez remarqué la présence systématique de cette déclaration dans nos exemples :

anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Cette section détaille les impératifs de sécurité associés à cette variable — un aspect critique à ne pas négliger. La configuration de la clé ANTHROPIC_API_KEY abordée à l'article 04 renvoyait à cette section pour son intégration dans les environnements d'intégration continue (CI).

Rappelons l'avertissement de sécurité majeur de la documentation :

永远不要直接将 API 密钥提交到您的仓库。

Pourquoi s'agit-il d'une ligne rouge ? Parce que les dépôts GitHub (notamment publics) sont visibles de tous. Écrire une clé active sous la forme sk-ant-xxxx dans votre fichier YAML équivaut à publier vos identifiants bancaires en clair. Des robots automatisés parcourent continuellement les dépôts à la recherche de clés exposées, ce qui entraînerait une facturation immédiate et massive à votre charge.

La seule méthode conforme est d'utiliser les Secrets GitHub : ne codez jamais d'identifiants en dur. La documentation décrit la marche à suivre :

• 将您的 API 密钥添加为名为 ANTHROPIC_API_KEY 的仓库密钥
• 在工作流中引用它：anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

Analogie : sécuriser une clé physique dans un coffre et n'utiliser qu'un code d'accès dans les plannings. GitHub Secrets joue le rôle de ce coffre-fort chiffré intégré à votre dépôt. La clé y est stockée sous forme cryptée et n'apparaît jamais dans les logs d'exécution ou les interfaces. La syntaxe ${{ secrets.ANTHROPIC_API_KEY }} déclarée dans votre YAML est uniquement une référence d'appel au coffre-fort. Le fichier de configuration peut ainsi être partagé publiquement sans exposer de données sensibles.

Comment ajouter la clé dans ce coffre-fort ? Manuellement : accédez aux paramètres du dépôt (Settings → Secrets and variables → Actions), cliquez sur New repository secret, nommez-le ANTHROPIC_API_KEY et insérez votre clé (récupérée sur la console Anthropic comme décrit à l'article 04). Si vous avez exécuté la commande automatique /install-github-app, cette étape a déjà été réalisée pour vous.

Cette logique s'accorde avec les principes de sécurité rappelés tout au long de cette série. L'article 21 mettait en garde contre les injections de requêtes (prompt injection), par lesquelles des tiers malveillants rédigent des instructions dissimulées dans les tickets ou commentaires pour manipuler l'agent. Soyez particulièrement vigilant sur le cloud car votre agent traite des textes saisis par des tiers externes. Appliquez systématiquement ces bonnes pratiques :

❌ Pratiques à risque	✅ Pratiques sécurisées
把真实 key 写进 YAML 提交	存进 GitHub Secrets，YAML 只引用
把权限开到最大图省事	只授必要的权限（Contents / Issues / PR 三项读写）
Claude 开的 PR 直接合	合并前自己审一遍
公开仓库随便让陌生人 @claude 派活	留意提示注入，敏感仓库收紧触发条件

L'exigence de relecture humaine avant fusion est fondamentale : le code produit par Claude reste une contribution externe à valider, et non une garantie de conformité absolue. Comme le souligne la documentation : « Relisez les suggestions de Claude avant fusion. » Adoptez cette règle d'or : considérez les PR de Claude comme le travail d'un développeur stagiaire. Ne fusionnez jamais sans avoir examiné attentivement les modifications au motif qu'elles semblent correctes à première vue.

💡 Résumé en une phrase : La sécurité exige de ne jamais stocker de clé en clair dans le dépôt ; enregistrez-la dans les Secrets GitHub et référencez-la via la variable ${{ secrets.ANTHROPIC_API_KEY }}. Associez-y les règles de moindre privilège, de validation humaine systématique et de prévention des injections pour sécuriser vos exécutions cloud.

---

07 Pratique : installer l'agent sur votre dépôt en 5 minutes

Passons à la pratique. Voici comment installer et valider le fonctionnement de l'agent sur un dépôt GitHub de test. Choisissez un dépôt secondaire sur lequel vous disposez des droits d'administration (évitez les dépôts de production). L'exercice ne requiert aucune configuration préexistante.

Prérequis : Disposer des droits d'administration sur le dépôt, utiliser l'API Anthropic directe (non Bedrock/Vertex) et avoir installé Claude Code en local. Veillez à ce que vos accès réseau vers les serveurs de GitHub et d'Anthropic soient opérationnels.

Étape 1 : Exécuter la commande d'installation locale

Placez-vous dans le répertoire de votre dépôt de test, lancez claude et saisissez :

/install-github-app

Résultat attendu : Un assistant de configuration s'ouvre, vous invitant à autoriser l'application Claude GitHub App dans votre navigateur. Sélectionnez votre dépôt de test, validez les trois droits d'accès (Contents, Issues, Pull requests) et laissez l'assistant enregistrer la clé ANTHROPIC_API_KEY dans les Secrets du dépôt. Suivez la procédure jusqu'à obtenir le message confirmant l'installation et l'écriture du workflow.

Étape 2 : Vérifier la création du fichier workflow

Vérifiez la présence du fichier suivant dans votre arborescence :

.github/workflows/claude.yml

Résultat attendu : Le fichier est présent et contient la structure de base (déclenchement sur issue_comment calling l'action v1). Sa présence valide la planification du service. Dans le cas contraire, reprenez l'étape 1.

Étape 3 : Valider l'enregistrement du secret

Accédez à la section Settings → Secrets and variables → Actions de votre dépôt GitHub.

Résultat attendu : Le secret ANTHROPIC_API_KEY figure dans la liste des secrets (sa valeur reste masquée par sécurité). Cette présence confirme la sécurisation de la clé.

Étape 4 : Ouvrir un ticket de test et mentionner l'agent

Créez un nouveau ticket (issue) sur votre dépôt et insérez une tâche simple dans la description, par exemple :

@claude 在 README 末尾加一行 "Hello from Claude Code GitHub Actions"，然后开个 PR

Résultat attendu :

• Dans l'onglet Actions du dépôt, un workflow nommé Claude Code doit apparaître à l'état En cours ou Terminé (icône verte).
• Après une à deux minutes de traitement (chargement du runner, récupération du code, modifications), Claude publie un commentaire sur le ticket et ouvre une PR contenant la ligne ajoutée au fichier README.
• L'apparition de cette pull request valide le bon fonctionnement de l'ensemble de la chaîne.

Si aucune action ne se produit après quelques minutes, appliquez les vérifications suivantes : avez-vous utilisé /claude au lieu de @claude, l'application est-elle bien installée, la clé secrète est-elle présente et l'exécution des Actions est-elle autorisée ? La confusion entre arobase et barre oblique est la cause de panne la plus courante.

Étape 5 : Relire et fusionner la PR

Ouvrez la pull request, inspectez le diff avec le même niveau d'exigence que pour un stagiaire, validez les modifications puis fusionnez-les.

En complétant ces étapes, vous avez configuré et testé la chaîne complète : installation de l'application, enregistrement du secret, planification, appel par mention, création de PR automatisée et validation humaine. La démarche reste identique pour tout dépôt de production, seules les conditions de déclenchement ou les requêtes variant.

💡 Résumé en une phrase : L'exercice pratique comporte cinq étapes : lancer /install-github-app → valider le fichier claude.yml → vérifier l'existence du secret → mentionner @claude dans un ticket pour lui attribuer une tâche → fusionner la PR après relecture humaine. Ce test valide concrètement votre infrastructure.

---

08 Récapitulatif

Dans cet article, nous avons déporté Claude Code sur le cloud : de la validation manuelle en direct à l'explication autonome déclenchée par un simple @claude, tout repose sur la puissance d'automatisation de GitHub Actions.

Voici une synthèse des points clés à retenir :

Objectif	Composant	Point clé
Comprendre son rôle	Claude Code hébergé sur GitHub	仓库事件触发，不用你在场，照读 CLAUDE.md
Mobiliser l'agent	Mention @claude dans les commentaires	认 @ 符号，不是 /claude
Procéder à l'installation	Commande locale /install-github-app	要管理员权限 + 直接 API；给三项读写工牌
Configurer déclencheurs et options	Workflow YAML dans .github/workflows/	on 定何时、claude_args 传参；v1 自动检测模式
Sélectionner le mode	Revue / Correctif / Planification	给 prompt 自动跑，不给等 @claude
Sécuriser les identifiants	Secrets GitHub	绝不硬编码，YAML 只用 ${{ secrets.* }} 引用

Vous êtes désormais en mesure de : expliquer la différence entre la version locale et la version GitHub Actions de Claude Code, utiliser la mention @claude (sans la confondre avec /claude) dans les PR et les tickets pour attribuer des tâches, modifier un workflow YAML de base, choisir la bonne configuration selon votre cas d'usage (revue, correctif ou planification), sécuriser votre clé API dans les Secrets GitHub et valider la configuration sur un dépôt de test. Cette automatisation cloud marque le passage de Claude du statut d'assistant local à celui de membre permanent d'astreinte 24h/24 dans votre équipe.

Une fois les Actions configurées, plus besoin de veiller tard en attendant qu'une PR soit relue : votre collaborateur de nuit s'en charge pendant que vous dormez.

Note : Si vous utilisez GitLab plutôt que GitHub, sachez qu'il existe une intégration similaire dans GitLab CI/CD (actuellement en phase bêta). La logique est identique : vous ajoutez une tâche dans .gitlab-ci.yml, déclarez une variable masquée, et déclenchez l'agent via @claude. Les principes étudiés pour GitHub s'appliquent de la même manière sur GitLab en se référant à sa documentation.

---

Le prochain article 45 « Agent SDK » — L'action GitHub Actions étudiée s'appuie sur le SDK Claude Agent. Autrement dit, cette capacité à créer automatiquement des PR repose sur un SDK vous permettant d'intégrer Claude Code dans n'importe quelle application via du code. GitHub Actions n'est que l'une des intégrations prêtes à l'emploi de ce SDK. Dans le prochain article, nous allons lever le voile sur son fonctionnement : si vous souhaitez concevoir des automatisations plus complexes que celles offertes par la mention @claude — comme créer un agent de support client personnalisé, traiter des milliers de fichiers par lots ou intégrer Claude dans vos outils de back-office —, comment piloter l'agent directement par programme ? GitHub Actions prend en charge les déclencheurs et l'exécution, mais pour personnaliser le flux complet (déclenchement, traitement et routage des résultats), il est temps de descendre d'un niveau.

---

Lectures recommandées

• Configuration des permissions : définir le niveau d'autonomie de l'agent
• Application de bureau (Desktop)
• Quatre workflows classiques : exploration, débogage, refactoring et écriture de tests