Managed Agents et Agent SDK : Claude en production autonome

Claude Cowork, l’article précédent, est l’agent qui travaille sur votre machine personnelle. Managed Agents est l’agent qui travaille dans le cloud, via l’API, pour des utilisateurs ou des processus de production. La distinction est fondamentale : Cowork est un outil individuel. Managed Agents est, lui, une infrastructure de déploiement.

Cet article est le treizième de la série « De zéro à machine de guerre ». Il s’adresse d’abord aux développeurs, CTO, équipes produit et intégrateurs. Mais il a aussi une utilité pour les non-développeurs : comprendre où va Claude. Les couches précédentes vous ont montré comment utiliser Claude en expert individuel. Ici, on regarde désormais comment les entreprises vont industrialiser ces usages.

Managed Agents : l’infrastructure clé en main

Construire un agent IA en production demande bien plus qu’un appel au modèle. Il faut également un environnement isolé pour exécuter du code, un système de fichiers, des permissions, des outils, des credentials, des logs, des événements, une gestion d’état et une façon de reprendre ou de piloter une session longue. Managed Agents fournit ce socle via la Claude Platform.

Le service est en public beta depuis le 8 avril 2026. Tous les endpoints Managed Agents nécessitent le header beta managed-agents-2026-04-01, que les SDK peuvent ajouter automatiquement. Depuis le 11 mai 2026, Managed Agents est aussi disponible via Claude Platform on AWS, avec les API Claude accessibles sur une infrastructure managée par Anthropic mais intégrée à AWS pour la facturation et l’authentification IAM.

Les quatre concepts à comprendre

Managed Agents repose sur quatre briques.

Cette séparation est importante. L’agent définit le comportement. L’environnement définit ensuite où il travaille. La session correspond à une tâche. Enfin, les événements permettent de suivre, piloter, interrompre ou reprendre le travail.

Les outils disponibles

Managed Agents donne à Claude des outils intégrés : bash, opérations de fichiers, web search, web fetch, MCP servers, Skills, fichiers attachés, accès GitHub, mémoire, vaults et webhooks selon configuration. L’intérêt n’est pas seulement d’avoir ces outils. L’intérêt est surtout de les avoir dans un runtime managé, avec une session durable et un historique persistant côté serveur.

Managed Agents vs Messages API : quand choisir quoi ?

La Messages API reste la bonne option quand vous voulez un appel modèle direct, un contrôle fin de chaque tour, ou votre propre boucle d’outils. Managed Agents devient pertinent quand votre agent doit travailler longtemps, manipuler des fichiers, lancer plusieurs outils, garder un état, attendre une action humaine, ou être suivi dans un environnement de production.

La règle pratique : si votre agent doit seulement répondre, utilisez la Messages API. S’il doit ensuite travailler, persister, manipuler des fichiers et être piloté dans le temps, regardez Managed Agents.

L’Agent SDK : construire des agents avec les outils de Claude Code

L’Agent SDK est une autre pièce du puzzle. Il ne faut pas le confondre avec Managed Agents. Managed Agents est une infrastructure cloud managée. L’Agent SDK est, lui, une bibliothèque Python et TypeScript qui permet d’utiliser le harness de Claude Code dans vos propres scripts, apps, CI/CD ou outils internes.

Le Claude Code SDK a été renommé Claude Agent SDK. Le changement reflète une réalité : le SDK ne sert pas seulement à coder, mais à construire des agents outillés capables de lire des fichiers, lancer des commandes, chercher sur le web, utiliser des MCP servers, gérer du contexte et déléguer à des subagents. Opus 4.7 nécessite l’Agent SDK v0.2.111 ou supérieur.

# Agent SDK — exemple Python simplifié
import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions

async def main():
    async for message in query(
        prompt="Lis auth.py, trouve le bug et propose un correctif.",
        options=ClaudeAgentOptions(
            model="claude-opus-4-7",
            allowed_tools=["Read", "Edit", "Bash"]
        ),
    ):
        print(message)

asyncio.run(main())

La différence avec un appel API classique : vous n’écrivez pas toute la boucle agentique. Le SDK fournit les outils, la gestion de contexte et la logique d’exécution qui font fonctionner Claude Code, mais sous forme programmable.

À utiliser quand vous voulez intégrer Claude dans un script, un pipeline de CI, un bot interne ou un outil développeur. Pour un service cloud long-running avec sessions persistantes et runtime managé, Managed Agents reste plus adapté.

Multiagent sessions : plusieurs agents dans une même session

Depuis le 11 mai 2026, les multiagent sessions de Managed Agents sont en public beta sous le header standard managed-agents-2026-04-01. Le principe : un agent coordinateur peut déléguer à d’autres agents, chacun avec son propre modèle, system prompt, outils, MCP servers et Skills.

Tous les agents partagent le même container et le même système de fichiers, mais chacun travaille dans son propre thread de session, avec son propre historique. Le coordinateur voit l’activité globale, peut recevoir les résultats, puis synthétiser. Les agents secondaires peuvent garder leur contexte d’un appel à l’autre dans la même session.

Cas où cela fonctionne bien :

• Parallelisation — analyser plusieurs documents, fichiers ou sources en parallèle.
• Spécialisation — confier la sécurité à un agent, la documentation à un autre, les tests à un troisième.
• Escalade — demander à un agent plus puissant ou plus spécialisé de traiter une sous-partie difficile.

Les limites sont nettes : un coordinateur ne peut déléguer qu’à un niveau d’agents, le roster peut référencer jusqu’à 20 agents uniques, et jusqu’à 25 threads concurrents sont supportés. Ce n’est donc pas une organisation infinie d’agents qui se reproduisent en cascade. C’est une orchestration contrôlée.

Outcomes : dire à l’agent ce que “terminé” veut dire

Autre nouveauté importante passée en public beta le 11 mai 2026 : les outcomes. Au lieu de simplement donner une tâche, vous définissez ce que le résultat final doit satisfaire, avec une grille de critères. Managed Agents provisionne alors un évaluateur séparé qui juge l’artifact produit selon cette grille, puis renvoie les écarts à l’agent pour qu’il itère.

C’est une différence majeure avec un simple prompt. Un prompt dit : « fais-moi un rapport ». Un outcome précise alors : « le rapport est terminé seulement s’il contient ces sections, ces sources, ce niveau de détail, ce format, ces contrôles qualité ». L’agent peut alors travailler en boucle jusqu’à atteindre le niveau attendu, dans la limite d’itérations définie.

# Exemple d'outcome — logique simplifiée
Objectif : produire un rapport concurrentiel en .docx.

Critères de réussite :
- 5 concurrents analysés
- Sources citées pour chaque prix et fonctionnalité
- Tableau comparatif lisible
- Recommandation finale en 10 lignes maximum
- Aucun chiffre non sourcé

Nombre maximal d'itérations : 5

Pour les usages de production, c’est probablement l’une des fonctions les plus importantes. Elle transforme l’agent en système orienté résultat, pas seulement en assistant qui exécute une instruction.

Memory stores : mémoire persistante pour agents

Les sessions Managed Agents démarrent fraîches par défaut. Depuis le 23 avril 2026, les memory stores sont en public beta : ils permettent à un agent de conserver du contexte entre sessions. Une mémoire peut stocker des préférences utilisateur, des conventions projet, des erreurs déjà rencontrées, du contexte métier ou des standards de sortie.

Techniquement, un memory store est une collection de documents texte montée comme un dossier dans le container de la session. L’agent lit ensuite et écrit dedans avec ses outils de fichiers. Chaque mémoire est adressée par un chemin, et chaque modification crée une version immuable, ce qui donne un historique et une possibilité de récupération.

Point de sécurité important : par défaut, une mémoire attachée peut être en lecture-écriture. Si l’agent traite des contenus non fiables — prompts utilisateurs, web, outils tiers — une injection pourrait écrire une mauvaise instruction dans la mémoire, puis être relue plus tard comme contexte de confiance. Pour les mémoires de référence, préférez le mode read-only.

Vaults et webhooks : deux briques de production

Les agents de production doivent agir pour le compte d’utilisateurs. Cela suppose donc des credentials. Les vaults permettent d’enregistrer des credentials par utilisateur ou par contexte, puis de les référencer au moment de créer une session. Vous n’avez pas à transmettre des tokens à chaque appel ni à reconstruire votre propre secret store pour tous les cas MCP. Depuis le 11 mai, les credentials mcp_oauth supportent aussi le background refresh.

Les webhooks, également ajoutés en mai, permettent de recevoir des événements de session et de cycle de vie des vaults. Ils sont essentiels pour les workflows human-in-the-loop : lancer un agent, le laisser travailler, puis notifier votre application quand il attend une validation, quand il passe idle, quand il termine ou quand un credential pose problème.

Sans vaults et webhooks, Managed Agents reste utilisable pour des prototypes. Avec eux, il devient beaucoup plus crédible pour des produits multi-utilisateurs.

Agent Teams dans Claude Code : à ne pas confondre

Le terme peut prêter à confusion. Multiagent sessions appartient à Managed Agents côté API. Agent Teams, en revanche, appartient à Claude Code. Les deux servent à coordonner plusieurs agents, mais ce ne sont pas la même surface.

Agent Teams permet de lancer plusieurs sessions Claude Code indépendantes avec un team lead, une liste de tâches partagée et une messagerie directe entre coéquipiers. Les teammates ont chacun leur propre fenêtre de contexte et peuvent se parler entre eux. Contrairement aux subagents, vous pouvez aussi interagir directement avec un teammate sans passer par le lead.

La fonctionnalité est expérimentale, désactivée par défaut, et nécessite Claude Code v2.1.32 ou plus. L’activation se fait avec CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Elle est surtout utile pour la recherche parallèle, les hypothèses de debug concurrentes, ou les features où chaque agent possède une partie indépendante. En revanche, elle est moins adaptée aux tâches séquentielles ou aux modifications du même fichier.

En clair : utilisez Agent Teams pour coordonner plusieurs Claude Code sur votre machine ou votre environnement dev. Utilisez Managed Agents multiagent sessions pour déployer une orchestration multi-agent côté API.

Combien ça coûte ?

Managed Agents est facturé sur deux dimensions : les tokens consommés et le runtime de session. Les tokens suivent les tarifs du modèle utilisé, comme dans l’API Claude classique. Le runtime est facturé 0,08 $ par session-hour, uniquement pendant que la session est en statut running. Le temps passé en attente d’un message utilisateur, d’une confirmation d’outil, en idle, rescheduling ou terminé ne compte pas.

Exemple officiel : une session d’une heure avec Claude Opus 4.7 consommant 50 000 tokens d’entrée et 15 000 tokens de sortie coûte environ 0,705 $ sans prompt caching. Si une grande partie du contexte est servie depuis le cache, le coût baisse ensuite. Le web search déclenché dans une session ajoute également son coût standard.

La facture peut donc monter vite avec les agents longs, les multiagent sessions et les outcomes itératifs. Chaque agent secondaire a son propre contexte. Les itérations consomment ensuite des tokens supplémentaires. Enfin, certains outils peuvent aussi ajouter leur propre coût. Avant de scaler, mesurez.

Cinq cas d’usage réalistes

Support client augmenté

Un agent lit un ticket, récupère l’historique client via MCP, cherche dans la base de connaissances, rédige une réponse, puis escalade si le cas dépasse son périmètre. Managed Agents devient utile si le flux contient plusieurs outils, des validations humaines et une mémoire par client.

Analyse financière ou documentaire

L’agent récupère plusieurs documents, extrait les chiffres, construit un modèle, produit un fichier Excel et s’auto-évalue avec un outcome. C’est un bon cas pour Managed Agents, parce qu’il combine fichiers, code, critères qualité et session longue.

Bug vers pull request

L’agent reçoit une alerte ou un bug, clone le repo, reproduit le problème, propose un correctif, lance les tests et prépare une PR. C’est exactement le type de workflow où sandbox, GitHub, webhooks et logs ont de la valeur.

Agent interne de reporting

Chaque semaine, un agent compile données CRM, tickets, métriques produit et notes d’équipe, puis produit un rapport. Une mémoire read-only peut contenir le format attendu, les définitions métier et les règles de présentation.

Orchestration multi-agent de recherche

Un coordinateur délègue à plusieurs agents : marché, concurrence, pricing, risques, synthèse. Chaque agent travaille sur un angle, puis le coordinateur assemble ensuite le résultat. À utiliser quand les sous-tâches sont vraiment parallèles, pas juste pour faire “plus agentique”.

Les limites à connaître

Beta publique ne veut pas dire stabilité parfaite

Managed Agents est en public beta. Les endpoints existent, les déploiements sont réels, mais les comportements peuvent évoluer. Pour une production critique, prévoyez tests, monitoring, fallback et limites de sécurité.

Infrastructure Anthropic par défaut

Les sessions tournent sur l’infrastructure managée d’Anthropic. Claude Platform on AWS change une partie du modèle d’intégration, mais il ne faut pas le confondre avec un déploiement on-premise ou un runtime que vous contrôlez entièrement. Les exigences de résidence, sécurité et conformité doivent être évaluées au cas par cas.

Multi-agent n’est pas magique

Plus d’agents signifie plus de coordination, plus de contexte, plus de coût et plus de surface d’erreur. Si les tâches sont séquentielles ou fortement dépendantes, un seul agent bien guidé sera souvent meilleur. Ainsi, le multi-agent doit rester une réponse à un vrai besoin de parallélisation, pas un réflexe.

La mémoire peut devenir un vecteur de risque

Une mémoire read-write alimentée par des contenus non fiables peut être polluée. Pour les références stables, utilisez read-only. Pour les préférences utilisateur, isolez les stores et surveillez ce qui s’écrit.

L’Agent SDK n’est pas un produit managé

Le SDK vous donne la boucle et les outils. En revanche, il ne gère pas pour vous toute l’infrastructure de production : scaling, webhooks métier, credentials utilisateurs, observabilité produit, facturation ou gouvernance. Si vous voulez externaliser cette couche, c’est Managed Agents qu’il faut regarder.

Ce que ça change pour l’écosystème Claude

Avec Managed Agents, Anthropic ne vend plus seulement un modèle ni une interface. L’entreprise fournit une pile complète : chat pour l’usage individuel, Projects et mémoire pour la personnalisation, MCP pour les outils, Skills pour les méthodes, Claude Code pour le développement, Cowork pour l’agent desktop, Managed Agents pour la production cloud.

Pour les utilisateurs de cette série, le message est simple : vous n’avez pas besoin de Managed Agents pour devenir excellent avec Claude. En revanche, comprendre cette couche vous aide aussi à voir où vont les usages en entreprise. Les workflows que vous construisez aujourd’hui à la main dans Claude deviendront demain des agents internes, outillés, monitorés et déployés à grande échelle.