Automatiser les workflows de développement avec Claude Code

Automatiser un workflow de développement avec Claude Code ne veut pas dire laisser un agent fusionner du code sans surveillance. La version fiable est plus précise : demander à Claude Code de résumer des Issue, préparer de petits changements, relire des PR, produire des rapports de maintenance, puis s’arrêter dès qu’une décision humaine est nécessaire.

Ce guide propose des exemples copiables avec gh, git, node, npm et claude. Le principe est de traiter l’automatisation comme un harnais : entrées contrôlées, actions autorisées, logs, reprises, rollback et points de validation humaine.

Définir la limite avant d’automatiser

Étape	Claude Code peut faire	La personne garde
Triage	Résumer Issue, diff et logs en échec	Priorité et décision produit
Changement	Petits correctifs, tests, documentation	Portée et décision de publication
Revue	Bugs, risques sécurité, tests manquants	Choix des suggestions à appliquer
Opérations	Contrôles planifiés, TODO anciens, dépendances	Merge, suppression, release, impact facturation

flowchart LR
  A["Issue / PR"] --> B["Prompt court"]
  B --> C["Claude Code"]
  C --> D["Diff et logs"]
  D --> E["Tests"]
  E --> F["Validation humaine"]
  F --> G["PR / release"]

Pour la vue CI/CD complète, lisez aussi le guide CI/CD avec Claude Code et le guide Hooks de Claude Code.

Cas d’usage 1 : créer une branche sûre depuis une Issue

Ce script lit une Issue GitHub, crée ou réutilise une branche déterministe, demande le plus petit changement utile à Claude Code, lance les tests et vous laisse décider du commit.

Enregistrez-le sous scripts/claude-issue-work.sh.

#!/usr/bin/env bash
set -euo pipefail

ISSUE_NUMBER="${1:-}"
if [ -z "$ISSUE_NUMBER" ]; then
  echo "Usage: ./scripts/claude-issue-work.sh <issue-number>"
  exit 1
fi

for command_name in git gh claude npm; do
  if ! command -v "$command_name" >/dev/null 2>&1; then
    echo "Missing command: $command_name"
    exit 1
  fi
done

: "${ANTHROPIC_API_KEY:?Set ANTHROPIC_API_KEY before running this script}"

mkdir -p .claude-logs
ISSUE_FILE=".claude-logs/issue-${ISSUE_NUMBER}.md"
LOG_FILE=".claude-logs/issue-${ISSUE_NUMBER}-$(date +%Y%m%d-%H%M%S).log"
BRANCH="claude/issue-${ISSUE_NUMBER}"

gh issue view "$ISSUE_NUMBER" --json title,body,labels --jq '
  "# " + .title + "\n\n" + (.body // "") + "\n\nLabels: " + ([.labels[].name] | join(", "))
' > "$ISSUE_FILE"

if git show-ref --verify --quiet "refs/heads/$BRANCH"; then
  git switch "$BRANCH"
else
  git switch -c "$BRANCH"
fi

PROMPT=$(cat <<PROMPT
Vous êtes l'assistant de développement de ce dépôt.
Lisez l'Issue ci-dessous et appliquez le plus petit changement utile.

Contraintes:
- Inspecter les fichiers liés avant toute modification.
- Respecter l'architecture, les noms et le style de test existants.
- Si l'exigence est ambiguë, laisser un TODO ou une question au lieu d'inventer une grande conception.
- Ne pas toucher aux secrets, fichiers d'environnement ni articles sans rapport.
- Laisser le dépôt prêt pour npm test.
- Ne pas commit, push, créer de PR ni merge.

Issue:
$(cat "$ISSUE_FILE")
PROMPT
)

claude -p "$PROMPT" \
  --max-turns 8 \
  --permission-mode acceptEdits \
  --output-format text 2>&1 | tee "$LOG_FILE"

npm test 2>&1 | tee -a "$LOG_FILE"
git diff --stat | tee -a "$LOG_FILE"

echo "Review the diff, then commit manually if it is correct."
echo "Log: $LOG_FILE"

Ces garde-fous évitent les incidents courants. Sans ANTHROPIC_API_KEY, le script s’arrête tout de suite. Le nom de branche est stable, donc une relance ne crée pas de doublon. Les logs restent dans .claude-logs, ce qui facilite l’audit du prompt et de l’échec de test.

Cas d’usage 2 : ajouter une revue PR dans GitHub Actions

L’action officielle Claude Code pour GitHub Actions peut s’exécuter sur les événements PR. Le workflow suivant demande une revue seulement : pas de modification, pas de push, pas de merge.

Enregistrez-le sous .github/workflows/claude-review.yml.

name: Claude Review Gate

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

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

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

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Relisez cette Pull Request.
            Concentrez-vous sur bugs, sécurité, tests manquants, compatibilité descendante et logs opérationnels.
            Marquez chaque remarque en high, medium ou low et proposez une correction concrète.
            Ne modifiez pas le code, ne poussez pas et ne fusionnez pas.
          claude_args: |
            --max-turns 6
            --permission-mode plan

Gardez les permissions limitées. Pour une revue PR, contents: read et pull-requests: write suffisent souvent. Ajoutez issues: write seulement si le workflow commente aussi des Issue.

Avant de copier d’anciens exemples, vérifiez la référence officielle Claude Code CLI, la documentation officielle Claude Code GitHub Actions et la syntaxe GitHub Actions. Les exemples avec @beta ou direct_prompt doivent être migrés vers @v1 et prompt.

Cas d’usage 3 : rapport de maintenance avec Node.js

La maintenance planifiée n’a pas besoin de modifier le dépôt. Un rapport sur les tests en échec, gros diffs, TODO anciens, logs absents ou risques de rollback suffit souvent à éviter du travail répété.

Enregistrez ce fichier sous scripts/claude-maintenance.mjs.

#!/usr/bin/env node
import { spawnSync } from "node:child_process";
import { existsSync, mkdirSync, rmSync, writeFileSync } from "node:fs";
import { join } from "node:path";

const logDir = ".claude-logs";
const lockFile = join(logDir, "maintenance.lock");
const stamp = new Date().toISOString().replace(/[:.]/g, "-");
const logFile = join(logDir, `maintenance-${stamp}.log`);

function fail(message) {
  console.error(message);
  process.exit(1);
}

function run(command, args, options = {}) {
  const result = spawnSync(command, args, {
    encoding: "utf8",
    shell: process.platform === "win32",
    ...options,
  });

  const output = `${result.stdout || ""}${result.stderr || ""}`;
  if (result.status !== 0) {
    writeFileSync(logFile, output);
    fail(`Command failed: ${command} ${args.join(" ")}. See ${logFile}`);
  }
  return output;
}

if (!process.env.ANTHROPIC_API_KEY) {
  fail("Set ANTHROPIC_API_KEY before running this script.");
}

mkdirSync(logDir, { recursive: true });
if (existsSync(lockFile)) {
  fail(`Another maintenance run is active: ${lockFile}`);
}

writeFileSync(lockFile, String(process.pid));

try {
  const status = run("git", ["status", "--short"]);
  const tests = run("npm", ["test", "--", "--runInBand"]);
  const prompt = [
    "Vous êtes le relecteur de maintenance de ce dépôt.",
    "Lisez git status et la sortie de tests, puis résumez les risques du jour.",
    "Ne modifiez, supprimez, committez ni poussez rien.",
    "Regroupez par credentials / idempotency / retry / rollback / logs / human approval.",
    "",
    "git status:",
    status || "(clean)",
    "",
    "test output:",
    tests.slice(-12000),
  ].join("\n");

  const review = run("claude", [
    "-p",
    prompt,
    "--max-turns",
    "5",
    "--permission-mode",
    "plan",
    "--output-format",
    "text",
  ]);

  writeFileSync(logFile, review);
  console.log(`Maintenance report written to ${logFile}`);
} finally {
  rmSync(lockFile, { force: true });
}

Si votre projet n’utilise pas Jest, remplacez npm test -- --runInBand par la commande de test habituelle. Le script envoie seulement les 12000 derniers caractères pour éviter un prompt trop long.

Cas d’usage 4 : planifier avec cron ou le Planificateur de tâches

Sous Linux et macOS, utilisez cron. Sous Windows, utilisez le Planificateur de tâches. Le schedule de GitHub Actions marche aussi, mais une exécution locale est souvent meilleure si la tâche dépend d’une base locale, d’un VPN ou d’identifiants internes.

# Exécution à 08:15 les jours ouvrés
15 8 * * 1-5 cd /path/to/repo && /usr/bin/node scripts/claude-maintenance.mjs >> .claude-logs/cron.log 2>&1

# Créer une tâche quotidienne Windows
schtasks /Create /TN "ClaudeMaintenance" /SC DAILY /ST 08:15 /F /TR "powershell -NoProfile -ExecutionPolicy Bypass -Command \"cd C:\path\to\repo; node scripts\claude-maintenance.mjs\""

Une tâche planifiée doit être idempotente : la relancer ne doit pas créer de PR, commentaire ou branche en double. Utilisez un verrou, des noms stables, une vérification d’état et des logs.

Cas d’usage 5 : écrire les validations humaines dans le prompt

Un prompt court n’est pas toujours plus sûr. Un bon prompt de workflow précise ce qui est autorisé, interdit et soumis à validation humaine.

claude -p "
Objectif:
  Appliquer les retours de revue sur la PR #123.

Autorisé:
  - Modifier les fichiers d'implémentation et de test liés.
  - Exécuter npm test.
  - Résumer les logs en échec.

Interdit:
  - git push
  - gh pr merge
  - Afficher .env ou des secrets
  - Refactorings sans rapport

Validation humaine requise:
  - Changement de compatibilité des réponses API
  - Migration de base de données
  - Suppression de tests existants

Rapport final:
  - Fichiers modifiés
  - Tests exécutés
  - Risques restants
  - Étapes de rollback
" --max-turns 6 --permission-mode acceptEdits

Pour structurer les revues, consultez la checklist de revue Claude Code et le workflow de reçu de vérification.

Modes d’échec à prévoir

Échec	Effet	Correctif pratique
Prompt trop long	Les contraintes se perdent, l’exécution ralentit	Passer seulement les fichiers utiles et la fin des logs
Identifiants manquants	CI échoue sur ANTHROPIC_API_KEY ou GH_TOKEN	Valider les variables au début
Pas d’idempotence	PR, commentaires ou branches en double	Noms stables, verrous, vérification d’état
Pas de logs	Personne ne sait ce que l’agent a tenté	Sauvegarder .claude-logs ou des artifacts GitHub
Reprise naïve	Un incident temporaire devient une écriture doublée	Réessayer les lectures puis revérifier l’état
Pas de rollback	Un gros commit est difficile à annuler	Petites PR et notes de rollback
Pas de validation	L’agent prend des décisions produit ou release	Compatibilité, données, facturation, suppression et merge restent humains

Pour aller plus loin, lisez l’audit sécurité Claude Code, les stratégies de test Claude Code et l’automatisation du workflow Git.

CTA de monétisation et AdSense

La conversion naturelle ici est l’aide pratique. Si vous travaillez seul, commencez avec la fiche gratuite Claude Code. Si votre équipe veut des prompts adaptés au dépôt, des portes de revue, une politique d’approbation et une formation, consultez la page formation et conseil Claude Code. Pour du matériel prêt à réutiliser, le guide de configuration Claude Code est l’option payante.

Évitez de placer des annonces ou CTA au milieu d’une séquence de commandes. Pour la qualité AdSense, cet article doit contenir du code exécutable, des échecs concrets, des liens officiels, des liens internes et un résultat testé.

Conclusion

L’automatisation Claude Code devient fiable quand les points d’arrêt sont conçus en premier. Commencez par le triage d’Issue et la revue PR, ajoutez ensuite de petites modifications, puis des contrôles planifiés et des portes CI avec validation humaine explicite.

Lors de l’essai de Masa, le meilleur gain n’a pas été la création automatique de PR, mais les logs d’Issue répétables et un prompt de revue PR fixe. L’absence de ANTHROPIC_API_KEY, une sortie de tests trop longue et la relance sur la même branche ont chacun provoqué un blocage ; les contrôles d’environnement, la coupe des logs et les noms de branche déterministes ont rendu le diagnostic suivant beaucoup plus simple.