GitHub Actions avancé avec Claude Code : permissions, OIDC, cache et matrix CI
Concevez des GitHub Actions plus sûrs avec Claude Code : permissions, OIDC, cache, matrix et YAML prêt à l'emploi.
GitHub Actions est simple quand il suffit de lancer des tests après un push. La difficulté arrive quand il faut réduire les permissions, fiabiliser le cache, tester plusieurs environnements, déployer vers le cloud sans clé longue durée et utiliser Claude Code sans exposer de secrets.
Ce guide utilise Claude Code comme partenaire de conception de workflow, pas comme distributeur de YAML. Les exemples ci-dessous sont des workflows complets que vous pouvez copier puis adapter. Le point essentiel est de pouvoir expliquer pourquoi chaque job a besoin de ses permissions, quels secrets il peut lire et ce qui se passe avec une pull request venant d’un fork.
J’ai vérifié les recommandations avec la documentation officielle GitHub sur workflow syntax, GITHUB_TOKEN permissions, AWS OIDC, dependency caching, concurrency et Claude Code GitHub Actions.
Architecture
Un workflow avancé n’est pas celui qui automatise tout. C’est celui qui limite le rayon d’impact, donne des erreurs lisibles, annule les runs obsolètes et garde une validation humaine pour les changements de production.
flowchart LR
PR["Pull request"] --> Gate["matrix test and lint"]
Gate --> Cache["lockfile cache"]
Gate --> Claude["Claude Code review"]
Gate --> Deploy["OIDC deploy"]
Deploy --> Env["GitHub environment approval"]
Env --> AWS["AWS role"]
Quelques termes doivent être clairs. Matrix est une table de combinaisons, par exemple Node.js 22 et 24 sur Ubuntu et Windows. OIDC, OpenID Connect, permet d’échanger une identité temporaire GitHub Actions contre des identifiants cloud de courte durée. Vous n’avez donc pas besoin de stocker de longues access keys AWS dans GitHub Secrets. Concurrency contrôle les exécutions simultanées. Permissions définit ce que le GITHUB_TOKEN peut faire.
Cas d’usage
Premier cas : un gate de qualité sur pull request. Lint, type-check et tests tournent sur plusieurs environnements avant le merge. Cela détecte les chemins cassés sous Windows, les différences de runtime Node.js et les lockfiles incohérents.
Deuxième cas : le déploiement staging. Quand main passe, GitHub Actions assume un IAM role AWS via OIDC et déploie sans clé statique. La production doit ajouter une approbation GitHub Environment.
Troisième cas : le CI partagé dans un monorepo. Si plusieurs packages répètent le même Node setup, install et test, un reusable workflow évite la dérive des versions d’actions.
Quatrième cas : la revue de pull request avec Claude Code. Commencez par l’analyse et les commentaires. Les permissions d’écriture doivent venir plus tard, avec branch protection, revue obligatoire et rollback.
Prompt pour Claude Code
Demandez d’abord une conception sous contraintes.
Design GitHub Actions for this repository.
The goals are pull request quality gates, staging deployment, and Claude Code review.
Constraints:
- Use least-privilege GITHUB_TOKEN permissions.
- Use OIDC for AWS. Do not store long-lived AWS access keys in Secrets.
- Include package-lock.json in dependency cache keys.
- Assume secrets are not available on forked pull requests.
- If pull_request_target is suggested, explain why PR head code is not checked out.
- Produce GitHub Actions YAML that is valid as written.
End with concrete failure cases and verification steps.
Ce prompt force Claude Code à justifier les décisions de sécurité au lieu de produire une configuration générique.
Gate de qualité PR
Ce workflow utilise actions/checkout@v6 et actions/setup-node@v6, versions majeures actuelles en juin 2026. Les runners hébergés par GitHub conviennent normalement. Avec des self-hosted runners, vérifiez d’abord leur version.
name: pr-quality-gate
on:
pull_request:
branches: [main]
push:
branches: [main]
permissions:
contents: read
concurrency:
group: pr-quality-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
jobs:
test:
name: node-${{ matrix.node }}-${{ matrix.os }}
runs-on: ${{ matrix.os }}
timeout-minutes: 15
strategy:
fail-fast: false
matrix:
os: [ubuntu-latest, windows-latest]
node: [22, 24]
steps:
- name: Checkout
uses: actions/checkout@v6
- name: Setup Node
uses: actions/setup-node@v6
with:
node-version: ${{ matrix.node }}
cache: npm
cache-dependency-path: package-lock.json
- name: Install dependencies
run: npm ci
- name: Lint
run: npm run lint
- name: Type check
run: npm run typecheck
- name: Test
run: npm test
Le job n’a besoin que de contents: read, car il ne modifie pas le dépôt. concurrency annule les runs anciens du même branch. Le cache dépend de package-lock.json; évitez de cacher tout node_modules sauf besoin très précis, car les modules natifs et les différences d’OS peuvent le rendre fragile.
Déployer sur AWS avec OIDC
Le modèle sûr consiste à enregistrer GitHub comme OIDC provider dans AWS, à créer un IAM role restreint et à limiter sa trust policy par repository, branch ou environment. Côté workflow, id-token: write est nécessaire pour demander le token OIDC.
name: deploy-staging
on:
workflow_dispatch:
push:
branches: [main]
permissions:
contents: read
id-token: write
concurrency:
group: deploy-staging
cancel-in-progress: false
jobs:
deploy:
runs-on: ubuntu-latest
timeout-minutes: 20
environment: staging
steps:
- name: Checkout
uses: actions/checkout@v6
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v6
with:
role-to-assume: arn:aws:iam::123456789012:role/claude-code-github-actions-staging
aws-region: ap-northeast-1
- name: Verify caller identity
run: aws sts get-caller-identity
- name: Deploy
run: |
npm ci
npm run build
echo "Deploy command goes here"
Remplacez le role ARN, la région et la commande de déploiement. Pour la production, utilisez un autre environment et des reviewers obligatoires.
Reusable workflow
Un reusable workflow est utile lorsque plusieurs workflows répètent le même contrôle. Il réduit aussi le risque qu’une ancienne version d’action reste dans un fichier oublié.
# .github/workflows/reusable-node-check.yml
name: reusable-node-check
on:
workflow_call:
inputs:
node-version:
required: false
type: string
default: "24"
permissions:
contents: read
jobs:
check:
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- name: Checkout
uses: actions/checkout@v6
- name: Setup Node
uses: actions/setup-node@v6
with:
node-version: ${{ inputs.node-version }}
cache: npm
cache-dependency-path: package-lock.json
- name: Install
run: npm ci
- name: Check
run: |
npm run lint
npm run typecheck
npm test
Workflow appelant :
# .github/workflows/ci.yml
name: ci
on:
pull_request:
branches: [main]
permissions:
contents: read
jobs:
node-check:
uses: ./.github/workflows/reusable-node-check.yml
with:
node-version: "24"
Ne masquez pas les vraies différences dans un énorme reusable workflow. Si chaque package a ses propres commandes, demandez à Claude Code de séparer le setup commun des étapes spécifiques.
Revue PR avec Claude Code
Claude Code Action v1 utilise anthropics/claude-code-action@v1, prompt et claude_args. Ne copiez pas les anciens exemples @beta ou direct_prompt.
name: claude-pr-review
on:
pull_request:
types: [opened, synchronize, reopened]
permissions:
contents: read
pull-requests: write
issues: write
jobs:
review:
if: github.event.pull_request.head.repo.full_name == github.repository
runs-on: ubuntu-latest
timeout-minutes: 20
steps:
- name: Checkout
uses: actions/checkout@v6
- name: Claude Code review
uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
prompt: |
Review this pull request as a senior engineer.
Focus on security, broken tests, unnecessary permissions, and missing verification.
Do not modify files. Leave concise review comments only.
claude_args: |
--max-turns 5
Le workflow saute les forks, car les secrets du dépôt n’y sont généralement pas disponibles. Pour les forks, prévoyez un chemin séparé sans secret et sans exécution de code externe avec permissions élevées.
Échecs fréquents
Le risque le plus sérieux est d’utiliser pull_request_target tout en checkout le head de la PR. Cet événement peut avoir des permissions proches du dépôt de base ; exécuter du code d’un fork externe devient dangereux.
Autre échec : afficher les secrets pour déboguer. GitHub masque de nombreuses valeurs exactes, mais les chaînes dérivées, JSON, base64 et logs d’outils tiers peuvent fuir. Donnez à Claude Code les noms et usages des secrets, jamais les valeurs.
Le cache peut aussi casser le build. Une key trop large comme node-cache peut restaurer des dépendances obsolètes après un changement de lockfile. Utilisez cache-dependency-path ou hashFiles('**/package-lock.json').
La matrix peut exploser. Deux OS et deux versions de Node.js restent raisonnables ; trois OS, quatre runtimes et huit packages donnent 96 jobs. Gardez une petite matrix sur PR et élargissez en nightly.
Enfin, surveillez les versions d’actions. En 2026, beaucoup d’actions officielles utilisent des runtimes Node plus récents. Avec des self-hosted runners, mettez le runner à jour avant les workflows.
Parcours de monétisation
Un CI plus sûr aide les pages qui rapportent : landing pages, templates payants, checkout, formulaires de leads et contenus de formation. Pour démarrer seul, utilisez la fiche gratuite Claude Code. Pour une équipe qui doit concevoir permissions, OIDC, revue Claude Code, branch protection et CI monorepo sur un dépôt réel, consultez la formation et consultation Claude Code.
À lire aussi : setup CI/CD, workflow Git, stratégie de tests et bonnes pratiques sécurité.
Résultat vérifié
Pour cet article, j’ai extrait les blocs YAML du MDX et les ai validés avec un parser YAML. Les exemples sont bien parsés et couvrent on, permissions, concurrency, matrix, reusable workflow, déploiement OIDC et Claude Code Action v1. Avant exécution, remplacez le role ARN AWS, les scripts npm, le nom d’environment et le secret ANTHROPIC_API_KEY.
PDF gratuit: cheatsheet Claude Code
Saisissez votre email et téléchargez une page avec commandes, habitudes de review et workflow sûr.
Nous protégeons vos données et n'envoyons pas de spam.
À propos de l'auteur
Masa
Ingénieur spécialisé dans les workflows pratiques avec Claude Code.
Articles liés
Workflow Obsidian vers CLAUDE.md avec Claude Code
Transformer des notes Obsidian en notes CLAUDE.md concises pour reprendre les sessions sans réexpliquer.
Claude Code Revenue CTA Routing : relier articles, PDF, Gumroad et consultation
Un workflow Claude Code pour orienter les lecteurs vers PDF gratuit, Gumroad ou consultation selon l'intention.
Règles de handoff Claude Code en équipe: preuves, permissions, rollback et revenus
Un format concret pour transmettre un travail Claude Code avec preuves, permissions, rollback, PDF gratuit, Gumroad et consultation.