Comment créer des workflows Claude automatisés

Il y a une phrase qui circule et qui résume la direction du codage agentique : l'objectif n'est pas une meilleure invite, c'est un flux de travail qui s'exécute sans que vous ayez à le surveiller. La plupart des gens utilisent Claude comme ils utiliseraient une fenêtre de chat. Vous tapez, vous attendez, vous lisez, vous tapez à nouveau. Cela fonctionne, mais cela limite votre production à un seul agent que vous surveillez activement. Les ingénieurs qui tirent un véritable avantage de Claude ont construit autre chose : des flux de travail qui se lancent selon un calendrier ou un déclencheur, effectuent le travail, vérifient leurs propres résultats et ne sollicitent un humain que lorsqu'une décision est nécessaire.

button

TL;DR

Un flux de travail Claude qui s'exécute sans vous nécessite cinq éléments : une spécification écrite précise, une exécution headless (non interactive), une porte de vérification déterministe qui décide du succès ou de l'échec, des garde-fous stricts (listes blanches de permissions, itérations bornées, plafonds de coûts, un interrupteur d'arrêt d'urgence), et un transfert qui notifie un humain ou escalade en cas d'échec. Le mode headless de Claude Code (claude -p), le SDK Claude Agent, les hooks et un ordonnanceur (cron ou launchd) vous offrent les cinq. L'agent n'est pas la partie risquée. L'exécuter sans surveillance, sans porte et sans garde-fous l'est. Construisez-les d'abord, puis lâchez prise.

Pourquoi « s'exécuter sans vous » est le véritable objectif

Le chat supervisé a un plafond rigide : vous. Chaque itération attend qu'un humain lise la sortie et décide de la suite. Le modèle génère en quelques secondes, puis reste inactif pendant des minutes pendant que vous changez de contexte. Vous êtes le goulot d'étranglement dans un système autrement rapide.

Les flux de travail non supervisés éliminent ce plafond. L'agent travaille, un script le vérifie, les échecs sont automatiquement redirigés, et vous n'intervenez qu'aux marges. Le gain n'est pas seulement la vitesse. C'est le parallélisme. Une fois qu'un flux de travail s'exécute sans supervision, vous évoluez en ajoutant des flux de travail, et non en tapant plus vite. C'est le même saut que nous avons abordé dans les flux de travail dynamiques de Claude Code, où une session se déploie en de nombreux agents parallèles.

Mais « s'exécuter sans vous » augmente les enjeux. Un agent supervisé qui fait une mauvaise modification est repéré lorsque vous lisez le diff. Un agent non supervisé la valide, exécute l'étape suivante et continue. La discipline passe donc de l'art de l'invite à la conception de système : vous construisez une machine qui doit être correcte, bornée et observable lorsque personne ne la regarde. L'article d'Anthropic sur la construction d'agents efficaces soutient le même argument. L'effet de levier provient de l'environnement autour du modèle, et non d'un message unique plus intelligent.

Les cinq éléments essentiels de tout flux de travail non supervisé

Sautez l'un de ces éléments et le flux de travail fera soit la mauvaise chose avec confiance, soit ne s'arrêtera jamais.

Une spécification précise. Une description écrite de ce qui est "terminé" que l'agent lit au début de chaque exécution. Des spécifications vagues produisent un travail vague. « Corriger l'API » échoue ; « le point de terminaison POST /orders renvoie 201, valide le corps par rapport au schéma, rejette les champs manquants avec 422 » réussit.
Exécution headless. Claude doit s'exécuter sans qu'un humain ne soit au clavier. Cela signifie un mode non interactif, et non l'interface utilisateur de chat.
Une porte de vérification. Un contrôle déterministe qui renvoie succès ou échec avec une raison concrète : des tests, une vérification de type, une validation de schéma, un test de contrat. C'est ce qui permet au flux de travail de décider qu'il est réellement terminé au lieu de se fier à la parole du modèle.
Des garde-fous. Des listes blanches de permissions, un nombre maximal d'itérations, un plafond de coûts, la journalisation et un interrupteur d'arrêt d'urgence. Ceux-ci empêchent une exécution confuse de causer des dommages pendant que vous dormez.
Un transfert. Lorsque le flux de travail est terminé ou abandonne, il en informe quelqu'un. Une notification, un brouillon pour révision, une alerte d'échec. Le silence n'est pas un succès.

Les trois éléments du milieu sont là où la plupart des configurations sont faibles. Construisons chacun avec les outils que Claude vous offre.

Les blocs de construction de Claude

Mode headless (claude -p)

Le mode d'impression de Claude Code exécute une invite de manière non interactive et se termine. C'est la base de tout flux de travail non supervisé. Vous lui donnez une tâche, restreignez ses outils, capturez la sortie et passez à autre chose.

claude -p "Implement the orders endpoint per spec.md, then run the test suite" \
  --allowedTools "Edit,Write,Bash" \
  --output-format json \
  >> run.log 2>&1

Le drapeau --allowedTools est plus important qu'il n'y paraît. Dans l'interface utilisateur de chat, vous approuvez chaque action à la main. En mode headless, il n'y a personne pour approuver, donc la liste blanche est votre seul contrôle sur ce que l'agent peut toucher. Commencez par une portée étroite et n'élargissez que lorsque vous faites confiance à l'exécution. L'ensemble complet des drapeaux se trouve dans la documentation de Claude Code.

Le SDK Claude Agent

Lorsqu'une commande shell ne suffit pas, le SDK Claude Agent vous permet de piloter Claude par programme depuis Python ou TypeScript. Vous obtenez la boucle dans le code : envoyez une tâche, diffusez le résultat, inspectez les appels d'outils, décidez de continuer. C'est ainsi que vous enveloppez un véritable flux de contrôle autour de l'agent.

import { query } from "@anthropic-ai/claude-agent-sdk";

const MAX_ITERATIONS = 8;
let feedback = "";

for (let attempt = 0; attempt < MAX_ITERATIONS; attempt++) {
  for await (const msg of query({
    prompt: `${task}\n\nPrevious failures:\n${feedback}`,
    options: { allowedTools: ["Edit", "Write", "Bash"] },
  })) {
    // diffuser/enregistrer les messages pendant que l'agent travaille
  }

  const gate = runVerification();      // votre vérification déterministe
  if (gate.passed) break;              // terminé
  feedback = gate.failures;            // la prochaine invite s'écrit d'elle-même
}

Les signatures exactes se trouvent dans la documentation, mais la forme est le point clé : une boucle qui réexécute l'agent avec la dernière défaillance comme prochaine invite. Si vous hésitez entre construire votre propre boucle et une option hébergée, notre comparaison entre les agents gérés et le SDK Agent explique quand chacun a du sens.

Hooks pour des garde-fous déterministes

Les hooks exécutent vos propres commandes à des points fixes du cycle de vie de Claude, sans implication du modèle. C'est ainsi que vous appliquez des règles que l'agent ne peut pas contourner. Vous voulez que la suite de tests s'exécute après chaque modification de fichier ? Un hook PostToolUse le fait de manière déterministe.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npm test --silent" }]
      }
    ]
  }
}

Parce qu'un hook est du code simple, et non une requête au modèle, il se déclenche toujours. C'est la propriété que vous recherchez pour les garde-fous dans une exécution non supervisée. L'agent ne peut pas décider de le sauter.

Un ordonnanceur pour déclencher les exécutions

Un flux de travail qui s'exécute sans vous a besoin de quelque chose pour le démarrer sans vous. Sur un serveur, c'est cron ; sur un Mac, c'est launchd. Dans tous les cas, vous déclenchez la commande headless selon un calendrier.

# tous les jours de semaine à 7h du matin : exécuter le flux de travail de maintenance, tout enregistrer
0 7 * * 1-5  cd /srv/api && claude -p "$(cat tasks/nightly-maintenance.md)" \
  --allowedTools "Edit,Bash" >> logs/run-$(date +\%F).log 2>&1

C'est l'épine dorsale d'une configuration autonome : un ordonnanceur déclenche Claude en mode headless, l'agent travaille selon une spécification, des hooks et une porte le maintiennent honnête, et les logs vous indiquent ce qui s'est passé.

Concevez la boucle, pas l'invite

Voici l'état d'esprit qui relie tout. Arrêtez de demander « que devrais-je dire à Claude ? » Commencez par demander « quelle boucle ferait en sorte que Claude se le dise lui-même ? » L'agent est un générateur rapide sans sens fiable de sa justesse. La boucle fournit ce sens via la porte. Nous avons approfondi ce sujet dans arrêtez de solliciter votre agent de codage, construisez la boucle à la place, et c'est l'idée porteuse pour le travail non supervisé : la confiance du modèle cesse d'avoir de l'importance, seul le verdict de la porte compte.

C'est aussi pourquoi une spécification claire l'emporte sur une invite astucieuse. La même spécification pilote chaque itération et sert également de documentation. Un fichier design.md ou AGENTS.md qui capture l'intention, les contraintes et la définition du travail terminé donne à l'agent une cible stable à chaque exécution, au lieu de vous obliger à réexpliquer le contexte à chaque fois.

Un exemple concret : maintenance d'API non supervisée

Concrétisons. Supposons que vous souhaitiez un flux de travail qui maintient un ensemble de points de terminaison API synchronisés avec leur spécification OpenAPI, s'exécute chaque matin et n'envoie jamais de point de terminaison défectueux. Voici la structure.

Spécification. Le contrat réside dans un fichier OpenAPI ; le comportement réside dans les cas de test. L'agent lit les deux au début de l'exécution.
Déclencheur. Une tâche cron à 7h du matin lance Claude en mode headless avec la tâche de maintenance.
Générer. L'agent réconcilie l'implémentation avec la spécification : ajoute les points de terminaison manquants, corrige les formes de réponse mal assorties, renforce la validation.
Porte. Le flux de travail exécute la suite de tests API contre le service en cours d'exécution. Assertions de statut, validation de schéma JSON sur chaque réponse, vérifications de contrat par rapport à la spécification. Les échecs sont structurés : « Attendu 422 sur customer_id manquant, reçu 500. » « Le champ de réponse total est une chaîne, le schéma indique un nombre. »
Boucle ou escalade. Porte rouge ? L'échec structuré devient la prochaine invite et l'agent corrige la lacune spécifique, jusqu'à la limite d'itération. Verte ? Il ouvre une PR de brouillon. Plus d'essais ? Il dépose une alerte avec la dernière défaillance et s'arrête.
Transfert. Un humain reçoit soit une PR propre à réviser, soit un rapport d'échec précis. Jamais un commit silencieux.

La porte de l'étape 4 est ce qui rend l'ensemble sûr à exécuter sans surveillance. Sans elle, l'agent modifie le code et signale un succès basé sur sa propre lecture, ce qui est exactement la façon dont les points de terminaison défectueux atteignent la production. C'est là qu'Apidog s'intègre dans un flux de travail autonome : la conception de l'API, le schéma, le serveur de maquette et les tests automatisés vivent dans un seul espace de travail, de sorte que la porte et la spécification restent synchronisées par défaut. Vous dirigez l'exécution vers un scénario de test Apidog et l'agent obtient un succès/échec validé par schéma à chaque itération. Le serveur de maquette remplace les dépendances qui ne sont pas opérationnelles, de sorte qu'une exécution à 3h du matin n'est pas bloquée en attendant un tiers instable. Les équipes qui câblent l'accès au point de terminaison de l'agent via le débogueur d'agent AI Apidog lui permettent d'atteindre et d'inspecter les points de terminaison de la même manière qu'un testeur humain. Téléchargez Apidog si vous préférez construire la porte visuellement plutôt que de coder un exécuteur à la main.

Des garde-fous pour sécuriser les exécutions non supervisées

C'est la partie qui sépare un flux de travail auquel vous faites confiance pendant la nuit de celui qui vous réveille à 3h du matin. Un agent non supervisé a besoin de limites strictes, pas de bonnes intentions.

Listes blanches de permissions étroites. En mode headless, la liste blanche est votre seule porte de contrôle sur ce que l'agent peut faire. Accordez le minimum d'outils nécessaires à la tâche. Ne donnez jamais à une exécution non supervisée un accès illimité au shell ou à des commandes destructrices sans sandbox.
Itérations bornées. Limitez la boucle. Une exécution qui ne peut pas atteindre une porte verte en N tentatives doit s'arrêter et escalader, et non tourner à l'infini.
Un plafond de coûts. Les boucles non supervisées consomment des tokens sans qu'un humain ne s'en aperçoive. Définissez une limite de dépenses et enregistrez les dépenses par exécution. Une boucle qui ne converge pas devrait déclencher la limite et s'arrêter. Nos notes sur la réduction des coûts des tokens d'agent s'appliquent directement ici.
Protégez la porte. Maintenez les fichiers de test et la spécification hors de l'ensemble des fichiers que l'agent peut modifier. S'il peut réécrire le test pour qu'il passe, vous avez construit une machine à simuler le progrès.
Une sandbox. Exécutez le travail non supervisé dans un espace de travail ou un conteneur isolé, pas sur la branche principale. Un git worktree ou une branche jetable contient le rayon d'action d'une mauvaise exécution.
Journalisation et interrupteur d'arrêt d'urgence. Capturez chaque exécution dans un journal que vous lisez réellement, et prévoyez un moyen d'arrêter une tâche en cours de vol. Vous ne pouvez pas déboguer ce que vous n'avez pas enregistré.
Approbation humaine aux marges. « Sans vous » ne signifie pas « sans personne, jamais. » Placez une personne au début (approuver la tâche) ou à la fin (approuver la PR), mais pas dans la boucle interne. Les schémas de câblage et les modes de défaillance ici s'alignent sur le câblage des outils de flux de travail agentique.

La plupart de ces éléments se résument à une seule règle : un agent non supervisé doit être capable de faire son travail et rien d'autre. Limitez les outils, bornez la boucle, isolez l'espace de travail et rendez chaque exécution observable.

Erreurs courantes

Quelques schémas coulent rapidement les flux de travail autonomes.

Pas de porte, juste des impressions. Si la seule vérification est « agent, as-tu fini ? », vous n'avez pas un flux de travail, vous avez un chatbot non supervisé. La porte doit être externe à l'agent.
Une tâche géante. Une exécution chargée de « maintenir l'ensemble du service » converge rarement. Décomposez-la en tâches de la taille d'un point de terminaison, chacune avec sa propre porte. Les petites exécutions se terminent ; les grandes s'agitent.
Permissions grandes ouvertes. Accorder chaque outil parce que c'est pratique transforme un petit bug en un incident majeur quand personne ne regarde. Utilisez des listes blanches strictes.
Succès silencieux ou échec silencieux. Un flux de travail qui valide sans prévenir personne, ou qui meurt sans alerte, est pire qu'aucun flux de travail. Toujours transférer.
Faire confiance à l'auto-déclaration du modèle. L'agent dira qu'il a terminé. La porte décide si c'est le cas. Construisez pour l'écart entre « semble terminé » et « est terminé », car sans surveillance, personne n'est là pour le détecter.

Si vous faites cela correctement, un flux de travail Claude effectuera une journée de travail borné et vérifié avant même que vous n'ayez bu votre café. Si vous vous trompez, vous aurez automatisé la production de code confiant mais non testé. La différence réside dans la porte et les garde-fous, pas dans le modèle. Si vous souhaitez une architecture plus approfondie, notre analyse de la conception du harnais d'agent explique comment les pièces s'assemblent à grande échelle.

Le point à retenir

Construire des flux de travail Claude qui s'exécutent sans vous est moins une question de Claude que du système que vous construisez autour. Cinq éléments portent le poids : une spécification précise, une exécution headless, une porte de vérification déterministe, des garde-fous stricts et un transfert propre. Si vous les maîtrisez, le modèle devient un travailleur rapide au sein d'une machine correcte, bornée et observable lorsque vous ne regardez pas.

Commencez par un flux de travail. Rédigez une spécification précise, exécutez-la en mode headless contre une porte de vérification rapide, listez les outils autorisés, limitez les itérations, isolez l'espace de travail et faites-la vous notifier en cas de succès ou d'échec. Pour tout ce qui touche aux API, votre suite de tests est la porte qui sécurise les exécutions non supervisées, et Apidog vous offre la conception, la simulation et les tests automatisés dans un seul espace de travail pour la construire. Téléchargez-le, câblez la porte et laissez le flux de travail faire ses tours pendant que vous faites autre chose.