CI/CD avec Claude Code : GitHub Actions sûr pour PR, déploiement et rollback

Demander à Claude Code de “créer le CI/CD” donne rapidement un fichier YAML. Le vrai sujet est ailleurs : ce workflow est-il assez sûr pour la production ? Un bon pipeline bloque les Pull Requests cassées, ne donne pas les Secrets aux forks, sépare staging et production, garde une approbation humaine pour publier, et prévoit un rollback clair.

Ici, Claude Code sert de partenaire de conception CI/CD, pas de distributeur de YAML. CI signifie intégration continue : lint, type check, tests et build à chaque changement. CD signifie livraison ou déploiement continu : un changement validé avance vers un environnement. Un gate est une condition obligatoire avant l’étape suivante. Les Secrets sont les valeurs privées comme les API keys. OIDC permet d’utiliser des identités temporaires au lieu de longues clés cloud stockées dans GitHub.

Gardez les sources officielles ouvertes : Claude Code GitHub Actions, GitHub Actions workflow syntax, GITHUB_TOKEN permissions, GitHub Secrets et GitHub Environments. Les exemples utilisent des GitHub-hosted runners avec actions/checkout@v6 et actions/setup-node@v6 au 3 juin 2026. Avec des self-hosted runners, vérifiez d’abord la version du runner.

Fixer la frontière d’automatisation

Avant d’écrire le workflow, décidez ce que Claude Code peut automatiser et ce qui reste humain. Claude Code peut lire le repository, proposer des jobs, analyser des logs et rédiger des corrections. Il ne doit pas élargir seul les permissions, décider d’une mise en production, imprimer des Secrets ou exécuter du code non fiable avec un événement privilégié.

Zone	Bon usage de Claude Code	Décision humaine
PR checks	Générer lint, test, typecheck, build	Checks requis et règles de merge
PR review	Signaler risques, permissions, tests manquants	Accepter ou refuser le patch
Déploiement	Brouillon staging/production	Approbation et portée des Secrets
Recovery	Résumer logs et proposer rollback	Exécuter rollback production

Commencez par un prompt contraint :

Design CI/CD for this repository.
The goals are pull request quality gates, staging deployment, Claude Code review, and production rollback.

Constraints:
- Use least-privilege GITHUB_TOKEN permissions per job.
- Do not use secrets on forked pull requests.
- If pull_request_target is suggested, explain why PR head code is not checked out.
- Put production deployment behind a GitHub Environment approval.
- Never print ANTHROPIC_API_KEY, DEPLOY_TOKEN, or other secret values.
- Produce workflow YAML that can be placed under .github/workflows/.

End with failure cases, verification commands, and rollback steps.

Ce prompt crée un harness, un cadre de travail sûr pour l’agent. Mettez les règles durables dans CLAUDE.md; la page CLAUDE.md best practices montre comment éviter les consignes trop floues.

Cas 1 : gate qualité pour Pull Request

Le premier workflow doit empêcher un merge non vérifié. Cet exemple lance lint, typecheck, tests et build, avec une matrix Node.js 22 et 24.

# .github/workflows/ci.yml
name: ci

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    name: test-node-${{ matrix.node-version }}
    runs-on: ubuntu-latest
    timeout-minutes: 15
    strategy:
      fail-fast: false
      matrix:
        node-version: [22, 24]
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v6
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm

      - run: npm ci
      - run: npm run lint --if-present
      - run: npm run typecheck --if-present
      - run: npm test -- --runInBand

  build:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    needs: test
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm

      - run: npm ci
      - run: npm run build

Dans un projet Node classique avec npm test et npm run build, ce workflow est directement exécutable. lint et typecheck utilisent --if-present pour faciliter la première migration. Ensuite, demandez à Claude Code de lire package.json et de retirer les gates fictifs. Pour choisir les bons tests, complétez avec testing strategies.

Cas 2 : revue PR Claude Code en lecture seule

Claude Code Action peut commenter les risques d’un PR : permissions GitHub Actions trop larges, Secrets exposés, tests manquants, rollback absent, fichiers hors scope. La première version doit commenter, pas modifier.

# .github/workflows/claude-pr-review.yml
name: claude-pr-review

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

permissions:
  contents: read
  pull-requests: write
  issues: write

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

jobs:
  review:
    if: >
      github.event.pull_request.draft == false &&
      github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v6
        with:
          persist-credentials: false

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          github_token: ${{ secrets.GITHUB_TOKEN }}
          prompt: |
            Review this pull request as a CI/CD safety reviewer.
            Focus on GitHub Actions permissions, secrets exposure, test coverage,
            deployment gates, rollback risk, and unrelated file changes.
            Do not edit files. Leave concise review comments with evidence.
          claude_args: |
            --max-turns 4

La condition sur le fork évite de lancer un workflow avec Secrets sur un PR externe. Pour les contributeurs externes, séparez un contrôle statique sans secret et un workflow privilégié déclenché après validation humaine. Méfiez-vous de pull_request_target, car il s’exécute dans le contexte du repository de base. Si Claude Code le propose, exigez une explication précise. Reliez cela à security best practices et Git workflow.

Cas 3 : gates de déploiement staging et production

Un point de départ solide consiste à déployer main vers staging automatiquement, puis à garder production derrière workflow_dispatch et GitHub Environment approval. Les Secrets production doivent vivre dans l’Environment production.

# .github/workflows/deploy.yml
name: deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  deployments: write

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: false

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run build

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    timeout-minutes: 10
    environment: staging
    env:
      APP_ENV: staging
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run deploy:staging

  deploy-production:
    if: github.event_name == 'workflow_dispatch'
    needs: deploy-staging
    runs-on: ubuntu-latest
    timeout-minutes: 10
    environment: production
    env:
      APP_ENV: production
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run deploy:production

Un push va jusqu’à staging. Production ne s’exécute qu’avec workflow_dispatch, puis l’Environment peut demander un reviewer. Ce simple découpage évite le classique “merge vers main, incident production immédiat”.

Cas 4 : rollback avant l’incident

Le rollback doit exister avant le premier incident. Ce workflow redéploie un SHA choisi manuellement, avec l’approbation production.

# .github/workflows/rollback-production.yml
name: rollback-production

on:
  workflow_dispatch:
    inputs:
      target_sha:
        description: "Commit SHA to redeploy to production"
        required: true
        type: string

permissions:
  contents: read
  deployments: write

jobs:
  rollback:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    environment: production
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ inputs.target_sha }}

      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm

      - run: npm ci
      - run: npm run build
      - run: npm run deploy:production

Demandez à Claude Code de relire deploy.yml et rollback-production.yml ensemble : ancien commit encore buildable, migrations réversibles, variables différentes entre staging et production, SHA actuellement déployé. Pour les logs, utilisez le build error triage loop.

Pièges fréquents

Premier piège : permissions: write-all. Cela débloque parfois le workflow, mais augmente fortement le rayon d’impact. Commencez avec contents: read.

Deuxième piège : imprimer les Secrets. Ne faites pas echo $DEPLOY_TOKEN. Vérifiez le nom et la portée, jamais la valeur.

Troisième piège : les faux gates. --if-present aide au démarrage, mais le gate final doit échouer si un script obligatoire manque.

Quatrième piège : envoyer un log géant à Claude Code. Donnez plutôt la première commande en échec, la première ligne utile, le résultat attendu et la commande de reproduction locale.

Monétisation et suite

Le CI/CD est un bon sujet de monétisation car le lecteur cherche à réduire un risque réel. Un développeur solo peut partir des ClaudeCodeLab products pour CLAUDE.md, prompts de revue et checklists. Une équipe qui doit intégrer branch protection, GitHub Actions, Secrets, approvals, rollback et revue Claude Code dans un vrai repository devrait passer par training and consultation.

Pour continuer, lisez Advanced GitHub Actions with Claude Code, testing strategies et security best practices. En pratique, le meilleur premier déploiement n’est pas l’automatisation production complète : commencez par le gate PR et la revue Claude Code en lecture seule, puis ajoutez staging, approbation production et rollback.