Créer des agents autonomes avec le SDK Claude Code : guide pratique pour développeurs

Construire des agents autonomes avec le Claude Code SDK : un guide pratique pour développeurs

Le Claude Code SDK — officiellement appelé l'Agent SDK — est une bibliothèque Python et TypeScript qui vous permet de piloter le moteur agentique complet de Claude Code de manière programmatique : pas de terminal, pas d'humain au clavier, juste votre application qui appelle une fonction asynchrone query() et qui reçoit en flux continu chaque étape du travail de l'agent. Si vous avez déjà utilisé Claude Code en mode interactif, le SDK vous offre cette même boucle lecture de fichiers / édition de code / exécution de commandes sous forme de bibliothèque composable que vous pouvez intégrer dans des pipelines CI, des bots de revue de code, des orchestrateurs multi-agents, ou n'importe quel service backend.

Qu'est-ce que l'Agent SDK — et pourquoi existe-t-il

Claude Code est bien connu comme un outil en ligne de commande. Vous saisissez un prompt, l'agent raisonne sur votre base de code, appelle des outils intégrés (Read, Edit, Bash, Grep, et d'autres), et vous renvoie les résultats. Mais dès que vous voulez automatiser cette boucle — déclencher une revue à chaque pull request, répartir la charge entre plusieurs sous-agents spécialisés, ou construire un produit par-dessus — le CLI interactif n'est plus la bonne abstraction. Il vous faut une bibliothèque.

L'Agent SDK comble ce manque. Selon la documentation officielle d'Anthropic, il expose « les mêmes outils, la même boucle d'agent et la même gestion du contexte qui alimentent Claude Code, programmables en Python et TypeScript ». Ce n'est pas un simple argument marketing — c'est littéralement l'architecture. Le SDK lance le binaire CLI de Claude Code en tant que sous-processus géré, communique avec lui via stdio, et expose tout sous forme de flux asynchrone d'objets messages typés que votre code peut consommer et auxquels il peut réagir.

Cette distinction compte pour plusieurs raisons :

Même moteur, interface différente. Lorsque vous passez du CLI au SDK, vous ne migrez pas vers un outil moins puissant ou plus simple. Le SDK hérite de toutes les capacités du CLI — connectivité aux serveurs MCP, cycle de vie des hooks, fichiers de skills, mémoire CLAUDE.md, délégation à des sous-agents, et l'ensemble complet des outils.

Le SDK exécute les outils à votre place. Si vous utilisez le Anthropic Client SDK (le package Python/JS anthropic de plus bas niveau) et que vous voulez que Claude appelle des outils, vous devez implémenter vous-même la boucle d'outils : appeler l'API, détecter une réponse d'utilisation d'outil, exécuter l'outil, renvoyer le résultat, répéter jusqu'à ce que Claude s'arrête. L'Agent SDK réduit toute cette boucle à un simple async for message in query(...) — Claude décide quels outils appeler, les exécute dans son sous-processus, et continue de boucler jusqu'à ce que la tâche soit terminée. Vous n'avez qu'à consommer le flux.

Conçu pour fonctionner sans supervision (headless). Les invites de permission du CLI — « autoriser cette commande bash ? » — bloquent en attendant une saisie humaine. Le SDK les remplace par une option permissionMode et un ensemble de modes de permission — par exemple acceptEdits pour approuver automatiquement les modifications de fichiers, et bypassPermissions pour tout exécuter sans invite dans un environnement CI en bac à sable — plus un callback d'approbation programmatique pour des flux personnalisés. Les noms exacts des modes et leurs comportements sont documentés dans la référence du SDK d'Anthropic (consultez-la pour la liste actuelle), mais l'effet est le même : votre automatisation n'est jamais bloquée en attendant une frappe au clavier.

Le même moteur Claude Code, deux interfaces : le CLI interactif pour le travail avec un humain dans la boucle, l'Agent SDK pour une automatisation programmatique et sans supervision où votre application contrôle le prompt et un mode de permission remplace la boîte de dialogue d'approbation.

Installer le SDK

Anthropic publie deux packages :

• TypeScript : @anthropic-ai/claude-agent-sdk (npm)
• Python : claude-agent-sdk (pip ; nécessite Python 3.10+)

Le package TypeScript embarque un binaire natif de Claude Code pour votre plateforme, donc aucune installation séparée du CLI n'est nécessaire. L'authentification se fait via une variable d'environnement ANTHROPIC_API_KEY obtenue depuis la Console Anthropic. Le SDK prend également en charge Amazon Bedrock, Google Vertex AI et Microsoft Azure AI Foundry — consultez la documentation d'Anthropic pour les schémas de variables d'environnement correspondants.

Concepts fondamentaux

Comprendre quatre concepts couvre la grande majorité des usages réels du SDK.

1. La fonction query() et le flux de messages asynchrone

Chaque interaction avec le SDK commence par query(). Vous passez une chaîne prompt et un objet options ; en retour, vous obtenez un itérateur asynchrone qui produit des objets messages typés au fur et à mesure que l'agent travaille. La boucle se termine lorsque l'agent a terminé ou rencontre une erreur.

Les messages que vous recevez incluent :

• AssistantMessage — le texte de raisonnement de Claude et les descriptions d'appels d'outils
• ToolResultMessage — le résultat de chaque exécution d'outil
• ResultMessage — le résultat final, avec un champ subtype indiquant le succès ou l'échec
• SystemMessage — les événements du cycle de vie de la session (le sous-type init porte le session_id)

Dans la majorité du code de production, vous filtrez pour ResultMessage afin d'extraire le résultat final, et éventuellement vous journalisez les blocs AssistantMessage pour tracer ce que l'agent a fait.

2. Les outils et allowedTools

L'ensemble d'outils intégrés du SDK correspond directement aux capacités de Claude Code :

L'option allowedTools pré-approuve un sous-ensemble de ces outils, accordant effectivement à l'agent la permission de les appeler sans aucune autre validation. Un agent d'audit en lecture seule pourrait ne lister que ["Read", "Glob", "Grep"] ; une automatisation complète pourrait inclure ["Read", "Edit", "Bash", "Glob", "Grep"].

3. Les modes de permission

Les modes de permission contrôlent ce qui se passe lorsque l'agent veut utiliser un outil qui n'est pas pré-approuvé dans allowedTools :

• acceptEdits — approuve automatiquement les modifications de fichiers et les opérations courantes du système de fichiers ; demande une confirmation pour tout le reste. Idéal pour les flux de développement de confiance.
• dontAsk — refuse silencieusement tout ce qui n'est pas dans allowedTools. Idéal pour les agents sans supervision et verrouillés.
• bypassPermissions — exécute chaque outil sans aucune validation. À utiliser uniquement dans un environnement en bac à sable.

Le SDK expose également un callback d'approbation programmatique vous permettant d'implémenter une logique d'approbation entièrement personnalisée, et la liste des modes disponibles peut évoluer avec le temps — consultez la référence du SDK d'Anthropic pour la liste actuelle et faisant autorité, ainsi que le comportement exact de chacun. En CI, vous utiliserez presque toujours une configuration étroitement délimitée et par défaut restrictive, ou bypassPermissions dans un conteneur en bac à sable que vous contrôlez.

4. Sessions, reprise et contexte

Chaque appel à query() crée (ou reprend) une session. Le session_id de la session arrive dans le premier SystemMessage avec subtype === "init". Vous pouvez le capturer et le passer en tant que resume: sessionId dans un appel ultérieur pour reprendre exactement là où la conversation s'est arrêtée — mêmes lectures de fichiers, même historique de raisonnement, même fenêtre de contexte.

C'est ainsi que vous construisez des agents multi-tours : un appel à query() analyse un module, capture le session_id, et un second appel à query() (avec resume) fait référence à « lui » ou « le fichier que vous venez de lire » sans avoir à tout réexpliquer. Les transcriptions de session sont écrites sur le disque local par défaut ; pour la production, vous pouvez attacher un adaptateur SessionStore adossé à S3, Redis, ou Postgres afin que les sessions survivent aux redémarrages de conteneurs.

Modèle de construction 1 : un bot de revue de code en CI

C'est le cas d'usage canonique de « l'automatisation sans supervision ». À chaque pull request, un job CI extrait la branche, exécute un agent qui lit les fichiers modifiés, et publie un commentaire de revue.

Le flux :

1. Un événement de PR déclenche un workflow GitHub Actions (ou un job GitLab CI).
2. Le runner extrait la branche et exécute votre script de revue.
3. Votre script appelle query() avec un prompt de revue, allowedTools: ["Read", "Glob", "Grep", "Bash"], et permissionMode: "dontAsk".
4. Claude lit le diff, recherche des motifs, raisonne sur les constats.
5. Le ResultMessage porte le texte de la revue ; votre script le publie sur la PR via l'API GitHub.

Le choix de conception clé consiste à utiliser dontAsk avec une liste d'outils en lecture seule. L'agent ne peut pas écrire de fichiers ni effectuer d'appels réseau au-delà de ce que les outils autorisent, donc votre job CI ne peut pas accidentellement fusionner des commits ou appeler des API externes. Une limite maxTurns (définie dans les options) borne la profondeur de l'agent afin que des boucles incontrôlées ne consomment pas de budget.

Pour une illustration de l'architecture de ce flux, voir le diagramme ci-dessous.

Un pipeline de revue de code entièrement automatisé. L'agent SDK s'exécute dans un conteneur CI avec une liste d'outils en lecture seule ; les constats reviennent sous forme de ResultMessage et votre code les publie comme commentaire de PR GitHub. L'agent n'écrit jamais de fichiers, ne quitte jamais le conteneur.

Vous pouvez étendre ce modèle avec des hooks — une fonctionnalité du SDK couverte dans notre guide approfondi sur les hooks de Claude Code — pour journaliser chaque appel d'outil dans un fichier d'audit, bloquer la lecture de chemins de fichiers spécifiques, ou émettre de la télémétrie structurée en parallèle de la revue.

Modèle de construction 2 : chaînes d'outils multi-agents

L'option agents du SDK vous permet de définir des sous-agents nommés, chacun avec son propre prompt système, sa liste d'outils et ses permissions. Votre agent principal leur délègue du travail via l'outil intégré Agent. Les messages des sous-agents incluent un champ parent_tool_use_id afin que vous puissiez tracer exactement quelle délégation a produit chaque élément de résultat.

Un exemple concret : une chaîne d'agents d'audit de sécurité où un sous-agent code-scanner recherche des vulnérabilités potentielles avec Grep et Glob, un sous-agent dependency-checker exécute Bash pour interroger les métadonnées de vos packages, et un agent coordinateur synthétise les deux rapports en un audit unifié. Chaque sous-agent dispose de l'accès minimal aux outils nécessaire pour son rôle, ce qui limite le rayon d'impact si un sous-agent hallucine une commande dangereuse.

Les chaînes multi-agents fonctionnent bien pour des tâches qui se décomposent naturellement : un agent par préoccupation, chacun avec une liste d'outils restreinte, orchestrés par un coordinateur qui n'a besoin que de Read et Agent. Pour un aperçu plus large de la façon dont les architectures multi-agents s'articulent avec des fonctionnalités de Claude Code comme la mémoire CLAUDE.md et les fichiers de skills, voir notre guide d'ingénierie de harnais.

Modèle de construction 3 : pipelines d'automatisation sans supervision

Au-delà de la revue de code, le SDK excelle dans toute automatisation récurrente où l'agent est une étape d'un pipeline plus large :

Audits de dépendances nocturnes. Un job cron appelle query() avec un prompt pour vérifier les packages obsolètes, exécuter des scanners de sécurité, et produire un rapport structuré. L'outil Bash exécute npm audit ou pip check ; Read inspecte les fichiers de verrouillage. Le ResultMessage alimente une notification Slack.

Traduction et i18n à la fusion d'une PR. Lorsqu'une PR est fusionnée, un webhook déclenche un agent qui lit les fichiers de chaînes modifiés avec Glob et Read, produit des versions traduites avec Write, et ouvre une nouvelle PR via Bash (en exécutant gh pr create).

Détection d'anomalies dans les logs. Injectez la sortie de logs récente dans un prompt query(). L'agent lit des fichiers de contexte supplémentaires si nécessaire, raisonne sur les logs, et émet un constat structuré. Aucune écriture de fichier n'est requise ; une liste d'outils en lecture seule suffit.

Synchronisation de la documentation. Après la fusion des PR, un agent lit les fichiers sources mis à jour et réécrit les pages de documentation correspondantes, puis valide les modifications. Le permissionMode: "acceptEdits" gère les écritures de fichiers sans demander de confirmation.

Le fil conducteur : query() remplace une intégration LLM sur mesure. Vous n'avez pas à implémenter une boucle d'outils, à gérer manuellement les fenêtres de contexte, ni à analyser la sortie du modèle pour décider quoi exécuter ensuite. L'agent gère l'orchestration ; vous fournissez le prompt et consommez le résultat.

Un exemple concret illustratif : un agent de correction de bugs

Le guide de démarrage rapide officiel démontre ce modèle de manière claire (le code ci-dessous suit l'API documentée — vérifiez la syntaxe exacte dans le guide de démarrage rapide d'Anthropic) :

Python illustratif (vérifiez l'API exacte dans la documentation officielle) :

# Illustrative — confirm exact import paths and option names in official docs
import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, AssistantMessage, ResultMessage

async def run_bug_fixer(file_path: str):
    async for message in query(
        prompt=f"Review {file_path} for bugs that would cause crashes. Fix any issues.",
        options=ClaudeAgentOptions(
            allowed_tools=["Read", "Edit", "Glob"],
            permission_mode="acceptEdits",
        ),
    ):
        if isinstance(message, AssistantMessage):
            for block in message.content:
                if hasattr(block, "text"):
                    print(block.text)
        elif isinstance(message, ResultMessage):
            print(f"Completed: {message.subtype}")

asyncio.run(run_bug_fixer("src/utils.py"))

TypeScript illustratif (vérifiez l'API exacte dans la documentation officielle) :

// Illustrative — confirm exact import paths and option names in official docs
import { query } from "@anthropic-ai/claude-agent-sdk";

for await (const message of query({
  prompt: "Review src/utils.ts for crash-causing bugs and fix them.",
  options: {
    allowedTools: ["Read", "Edit", "Glob"],
    permissionMode: "acceptEdits",
  },
})) {
  if (message.type === "assistant" && message.message?.content) {
    for (const block of message.message.content) {
      if ("text" in block) console.log(block.text);
    }
  }
  if (message.type === "result") console.log("Done:", message.subtype);
}

Ce qui se passe lorsque cela s'exécute : Claude lit utils.py (ou .ts) à l'aide de l'outil Read, raisonne sur le code, identifie des cas limites, puis appelle Edit pour insérer une gestion défensive. Vous voyez le raisonnement et les appels d'outils défiler sous forme d'objets AssistantMessage ; le ResultMessage final signale l'achèvement. Toute la boucle de l'agent — y compris la relecture du fichier pour vérifier la modification — est gérée par le SDK.

C'est ce qui rend le SDK différent d'un appel direct à l'API des modèles Anthropic : vous n'implémentez pas la couche d'exécution des outils. Claude décide quand appeler Read, l'appelle, récupère le contenu du fichier, et poursuit son raisonnement. La boucle est autonome.

Permissions, bac à sable et sécurité en production

Exécuter des agents autonomes en production nécessite de réfléchir attentivement à ce qu'ils peuvent toucher. Le SDK fournit plusieurs contrôles superposés.

Le cadrage des outils est la première ligne de défense. Si un agent n'a pas besoin de Bash, ne l'incluez pas dans allowedTools. Un agent disposant seulement de ["Read", "Glob", "Grep"] ne peut pas modifier de fichiers, exécuter de commandes shell, ni effectuer d'appels réseau, quel que soit ce que dit son prompt.

Les modes de permission fournissent un second verrou. dontAsk garantit que tout ce qui est hors de allowedTools est silencieusement refusé plutôt que de demander confirmation. C'est crucial dans les environnements sans supervision — un prompt qui reste bloqué en attendant une saisie utilisateur va bloquer votre pipeline.

L'option cwd délimite l'accès de l'agent au système de fichiers à un répertoire spécifique. Dans les environnements multi-tenants, passez un répertoire de travail par session afin que les agents de différents tenants ne puissent pas lire les fichiers les uns des autres.

L'isolation des tenants nécessite des étapes supplémentaires : définir settingSources: [] pour qu'aucun paramètre du système de fichiers ne fuite entre tenants ; définir CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 pour empêcher le chargement de la mémoire automatique ; pointer CLAUDE_CONFIG_DIR vers un chemin par tenant. Cela est documenté en détail dans le guide d'hébergement d'Anthropic.

Le bac à sable en conteneur est l'enveloppe extérieure. Pour les agents de production ayant besoin d'un accès Bash, exécutez le SDK dans un conteneur avec une sortie réseau restreinte aux domaines que vous autorisez explicitement. Des fournisseurs comme Modal, E2B, Cloudflare Sandboxes, Fly Machines et Vercel Sandbox sont mentionnés dans la documentation d'Anthropic comme options pour des déploiements SDK en bac à sable.

maxTurns limite le nombre d'allers-retours d'utilisation d'outils, bornant à la fois le coût et les boucles incontrôlées. Définissez-le en fonction de la complexité attendue de votre tâche — une simple revue de lecture de fichier pourrait nécessiter 5 à 10 tours ; un refactoring complexe multi-fichiers pourrait en nécessiter 30 à 50.

Pour les équipes construisant des hooks et des flux de permission en production, notre guide des hooks de Claude Code couvre en détail le cycle de vie des hooks PreToolUse et PostToolUse, y compris comment écrire des callbacks de hook qui bloquent, transforment, ou journalisent les appels d'outils avant leur exécution.

MCP : connecter l'agent à des systèmes externes

Le SDK prend entièrement en charge le Model Context Protocol (MCP), qui vous permet de connecter votre agent à n'importe quel système externe exposant un serveur MCP : bases de données, automatisation de navigateur, Jira, Slack, GitHub, et des centaines de serveurs communautaires.

Vous configurez les serveurs MCP dans l'option mcpServers — chaque entrée spécifie une commande à exécuter et des arguments optionnels. Le SDK démarre ces serveurs en tant que sous-processus, et l'agent peut appeler leurs outils de la même manière qu'il appelle les outils intégrés. C'est ainsi que vous donnez à un agent de revue de code l'accès à votre gestionnaire de tickets, ou que vous connectez un agent de documentation à la base de connaissances de votre entreprise.

Le modèle de permission s'applique également aux appels d'outils MCP — allowedTools peut inclure des noms d'outils MCP, et permissionMode régit ce qui se passe pour les outils non listés.

Pièges et écueils courants

Les sessions sont locales au sous-processus par défaut. Les transcriptions de session résident sur le disque local de l'hôte, sous ~/.claude/projects/. Dans les déploiements conteneurisés ou mis à l'échelle horizontalement, cela signifie que l'état de session est perdu lors d'un redémarrage ou d'une réaffectation de nœud. Utilisez un adaptateur SessionStore pour toute session que vous devez pouvoir reprendre à travers plusieurs conteneurs.

Le modèle de sous-processus a des implications en mémoire. Chaque session en cours d'exécution est un sous-processus distinct. Exécuter cinquante sessions simultanées signifie cinquante processus Claude Code. La recommandation officielle est d'environ 1 Gio de RAM par agent comme point de départ, mais l'utilisation réelle de la mémoire dépend de la durée de session et de l'activité des outils. Dimensionnez vos conteneurs en conséquence et définissez maxTurns pour limiter la profondeur de session.

Les grands déploiements de sous-agents atteignent les limites de débit. Si votre orchestrateur délègue à vingt sous-agents simultanément, vous atteindrez probablement les limites de débit de l'API d'Anthropic. Découpez les larges déploiements en lots et ajoutez un petit délai entre les envois.

bypassPermissions nécessite un véritable bac à sable. Ce mode ignore tous les verrous de permission. Il est conçu pour des environnements entièrement contrôlés comme les conteneurs CI où vous possédez l'intégralité du contexte d'exécution. L'utiliser sur la machine d'un développeur — où l'agent a accès aux clés SSH, aux identifiants cloud, et à des chemins de fichiers arbitraires — constitue un risque de sécurité.

Le SDK TypeScript embarque le binaire Claude Code ; Python n'en a pas besoin séparément. Mais les deux SDK sont figés sur une version spécifique du CLI. Lorsque vous mettez à jour le package SDK, vous mettez également à jour le CLI sous-jacent. Consultez le changelog avant les montées de version mineures — les changements de comportement cassants y sont annoncés.

Le texte des prompts et les entrées d'outils ne sont pas inclus dans les exports OTEL par défaut. Il s'agit d'un comportement de confidentialité intentionnel. Si vous avez besoin d'une traçabilité au niveau du prompt pour le débogage, vous devez opter explicitement via des variables d'environnement documentées dans le guide d'observabilité d'Anthropic.

Les anciennes versions du SDK peuvent ne pas prendre en charge les nouveaux modèles. La documentation d'Anthropic note que les modèles récents peuvent nécessiter une version récente du SDK en raison de changements dans l'API du paramètre de réflexion (thinking), de sorte qu'un SDK obsolète peut échouer face à un nouveau modèle. Vérifiez toujours le changelog et figez une version connue comme fonctionnelle lors de l'adoption de nouveaux modèles.

Le SDK contre le CLI : lequel vous faut-il ?

Pour la plupart des développeurs, la réponse est les deux — et c'est voulu.

Le CLI interactif est le bon outil pour le développement au quotidien : explorer une base de code inconnue, résoudre un bug complexe de manière interactive, ou effectuer un refactoring ponctuel. Le SDK est le bon outil pour tout ce qui doit fonctionner sans présence humaine : CI, tâches planifiées, fonctionnalités d'application, et pipelines multi-agents.

Le SDK et le CLI ne sont pas des produits concurrents. Les flux de travail que vous développez de manière interactive avec le CLI se traduisent directement en automatisation SDK — mêmes outils, mêmes concepts de permission, même mémoire CLAUDE.md et système de skills. Un flux de revue que vous prototypez avec claude dans votre terminal aujourd'hui devient un bot CI propulsé par le SDK demain.

Pour les équipes utilisant la version web de Claude Code (couverte dans notre guide Claude Code sur le web), le SDK ouvre la voie à mélanger sessions web et orchestration programmatique — lancez une tâche longue depuis le web, puis connectez-vous à celle-ci de manière programmatique depuis votre backend.

Questions fréquemment posées

Qu'est-ce que le Claude Code SDK (Agent SDK) exactement ? C'est une bibliothèque Python (claude-agent-sdk) et TypeScript (@anthropic-ai/claude-agent-sdk) qui expose le moteur agentique complet de Claude Code — outils, permissions, gestion de session, sous-agents, MCP — sous forme d'API asynchrone programmable. Vous appelez query(), passez un prompt et des options, et récupérez en flux continu le travail de l'agent sous forme d'objets messages typés.

Ai-je besoin de Claude Code installé pour utiliser le SDK ? Pour le SDK TypeScript, non — le package embarque un binaire natif de Claude Code. Pour le SDK Python, le package claude-agent-sdk gère la dépendance. Vous avez cependant besoin d'une clé API Anthropic depuis la Console Anthropic.

Puis-je utiliser le SDK avec des modèles autres que Claude sur l'API d'Anthropic ? Oui. Le SDK prend en charge Amazon Bedrock, Google Vertex AI, Microsoft Azure AI Foundry, et Claude Platform sur AWS via des variables d'environnement. Vous pouvez également router les requêtes via un proxy personnalisé en définissant ANTHROPIC_BASE_URL.

Comment utiliser le SDK dans un workflow GitHub Actions ? Ajoutez votre ANTHROPIC_API_KEY en tant que secret GitHub Actions, extrayez la branche de la PR dans votre workflow, installez le package SDK, et exécutez votre script d'agent. Utilisez permissionMode: "dontAsk" avec une liste allowedTools en lecture seule afin que l'agent ne puisse pas modifier de fichiers dans votre environnement CI. La documentation d'Anthropic couvre également une intégration GitHub Actions dédiée qui automatise la revue de PR et le triage des issues sans écrire de code SDK personnalisé.

Quelle est la différence entre l'Agent SDK et Managed Agents ? L'Agent SDK est une bibliothèque qui exécute la boucle d'agent dans votre propre processus et votre propre infrastructure. Managed Agents est une API REST hébergée où Anthropic exécute l'agent et le bac à sable — vous envoyez des événements et recevez les résultats en flux continu. Le SDK est préférable pour le prototypage local et les agents qui travaillent directement sur votre système de fichiers ; Managed Agents est préférable en production lorsque vous ne voulez pas gérer d'infrastructure de conteneurs.

Comment limiter ce à quoi l'agent peut accéder ? Utilisez allowedTools pour restreindre les outils disponibles, permissionMode: "dontAsk" pour refuser tout ce qui est hors de cette liste, et cwd pour délimiter l'accès au système de fichiers à un répertoire spécifique. Pour les déploiements multi-tenants, définissez également settingSources: [] et CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.

Le SDK prend-il en charge la sortie en flux continu ? Oui — l'itérateur asynchrone de query() diffuse les messages en temps réel. Si vous n'avez pas besoin de sortie en direct (pour des tâches en arrière-plan ou des pipelines CI où seul le résultat final vous intéresse), la documentation d'Anthropic décrit un mode mono-tour qui collecte tous les messages avant de retourner un résultat. Voir Streaming vs. single-turn mode dans la documentation officielle.

Puis-je exécuter plusieurs agents en parallèle ? Oui. Chaque appel à query() lance un sous-processus indépendant. Vous pouvez exécuter N sessions simultanées — mais chacune est un processus séparé, donc provisionnez la mémoire en conséquence et soyez attentif aux limites de débit de l'API. Pour les déploiements simultanés de sous-agents depuis un seul orchestrateur, découpez vos envois en lots afin d'éviter d'atteindre les limites de débit.

Que se passe-t-il si la session plante en cours de tâche ? Par défaut, les transcriptions de session sont locales au conteneur et perdues lors d'un redémarrage. Pour survivre aux redémarrages, configurez un adaptateur SessionStore (S3, Redis, ou Postgres) et passez-le dans les options. Vous pouvez ensuite reprendre la session par session_id sur un conteneur neuf.

Exécuter des agents sans configuration locale

La proposition de valeur du SDK est l'automatisation — mais faire fonctionner cette automatisation nécessite une véritable infrastructure : un runtime Python ou Node, une clé API, une stratégie de conteneurs, une décision de bac à sable, et du temps consacré à la modélisation des permissions avant votre premier déploiement en production.

Pour les développeurs qui veulent itérer sur des idées d'agents sans cette lourdeur de configuration, Happycapy exécute des agents de style Claude Code directement dans le navigateur. Il n'y a pas d'installation locale, pas de gestion de sous-processus, et pas de provisionnement de conteneurs. Vous apportez un prompt, Happycapy gère l'environnement d'exécution — avec accès à plus de 150 modèles et un bac à sable cloud sécurisé. C'est une voie rapide pour prototyper le comportement d'agent que vous industrialiserez plus tard avec le SDK.

Commencez gratuitement sur happycapy.ai

Guides associés

• Claude Code Hooks: The Power-User Guide to Automating Your Agent
• How Claude Code Review Actually Works: Diffs, Hooks, and What the Agent Catches
• Claude Code Web: How to Run Claude Code in Your Browser (No Install)
• What Is Harness Engineering? Building Reliable AI Agent Harnesses (2026)