Qu'est-ce qu'un agent géré ?
Sur cette page
Jusqu’ici, c’est vous qui faisiez tourner la boucle de l’agent et qui hébergiez l’exécution de ses outils. Claude Managed Agents est une suite d’API pour construire et déployer des agents à grande échelle, sur l’infrastructure d’Anthropic. Vous définissez des agents (outils, personnalité, capacités), vous configurez des environnements (paquets installés, contrôle du réseau), puis vous lancez des sessions depuis votre application. Claude travaille dans un conteneur isolé, avec un système de fichiers, l’exécution de commandes et la recherche web.
Sous le capot, c’est la boucle d’agent de la leçon 4 : Claude raisonne, appelle un outil, lit le résultat, et recommence jusqu’à ce que le travail soit fait. Le service la fait tourner pour vous. Il a sa propre rubrique dans la Console Claude, et il est en bêta : toutes ses requêtes portent l’en-tête managed-agents-2026-04-01, que le SDK ajoute de lui-même.
Quatre façons de construire un agent
Deux questions séparent les approches : qui fournit le harnais (la boucle et la gestion du contexte) et qui fournit le déploiement (l’infrastructure où tourne l’agent).
| Approche | Ce que vous écrivez | Harnais et déploiement | Quand la choisir |
|---|---|---|---|
| Boucle manuelle (Messages API) | La boucle while vous-même | Vous construisez et hébergez tout | Vous voulez maîtriser toute la boucle |
| Tool Runner (SDK de l’API, en bêta) | Seulement vos fonctions d’outils | Le SDK fournit la boucle ; vous hébergez | Un agent sur vos propres outils, sans écrire la boucle |
| Claude Managed Agents | La configuration de l’agent et vos résultats d’outils | Anthropic fournit la boucle et héberge un bac à sable par session | Tâches longues, configurations versionnées, aucune infrastructure à gérer |
| Claude Agent SDK (produit distinct) | Un prompt et des options | Le harnais de Claude Code et ses outils ; vous hébergez | Un agent de code ou de fichiers « tout compris » sur votre infrastructure |
Seuls les agents gérés ajoutent le déploiement géré.
Quatre concepts
| Concept | Rôle |
|---|---|
| Agent | Le modèle, le prompt système, les outils, les serveurs MCP et les skills |
| Environnement | Où les sessions s’exécutent : un bac à sable dans le cloud géré par Anthropic, ou un bac à sable hébergé sur votre propre infrastructure |
| Session | Une instance de l’agent en cours d’exécution dans un environnement, qui accomplit une tâche et produit des résultats |
| Événements | Les messages échangés entre votre application et l’agent : messages de l’utilisateur, résultats d’outils, changements d’état |
Trois exemples de la leçon officielle
Un tableau Kanban qui fait le travail. Vous glissez le ticket « optimiser les performances du site » dans la colonne « en cours » : votre back-end crée une session. Son environnement a Lighthouse et Puppeteer préinstallés, et le dépôt GitHub est monté dans le conteneur. Une grille d’évaluation dit ce que « terminé » veut dire : score Lighthouse supérieur à 90, aucune ressource bloquant l’affichage, toutes les images chargées en différé. Claude lance l’audit, compresse les images, intègre le CSS critique, diffère les scripts, et chaque appel d’outil remonte en direct vers le tableau. Un évaluateur distinct, dans sa propre fenêtre de contexte, juge le résultat d’après la grille ; Claude lit son retour, corrige et soumet à nouveau. Dans la démonstration, le score monte à 96. Un second ticket glissé pendant ce temps ouvre une seconde session, dans un second conteneur, en parallèle.
Un agent de veille récurrent, avec mémoire. Chaque semaine, avant la réunion d’équipe, il suit les prix et les formules de tous les logiciels payés par l’entreprise. Il cherche les pages de tarifs sur le web, lance une analyse de coûts en Python dans le bac à sable, rédige une synthèse avec une skill de tableur, puis publie un lien dans Slack et crée une tâche de relecture dans Asana, par des serveurs MCP. Il lit sa mémoire avant de commencer et y range ce qui a changé : le rapport suivant peut dire « les coûts ont baissé de 15 % depuis la semaine dernière » au lieu de répéter les mêmes tarifs.
Une réponse à incident à plusieurs agents. Une alerte part de votre supervision ; votre back-end l’envoie comme message utilisateur dans une nouvelle session. Si l’agent a besoin de données de supervision, il appelle un outil personnalisé : votre back-end l’exécute et renvoie le résultat dans la même session. Un agent coordinateur délègue à trois spécialistes, chacun dans sa propre fenêtre de contexte, sur le même système de fichiers, puis réunit leurs conclusions en un seul rapport. Avant l’envoi dans Slack, la politique de permissions met l’action en attente : vous relisez le brouillon et vous l’approuvez. La mémoire relie le tout : le coordinateur y retrouve un incident semblable vieux de deux semaines et part de ce contexte au lieu de tout diagnostiquer à nouveau.
Les briques
| Brique | Rôle |
|---|---|
| Outils | Les outils intégrés (commandes, fichiers, web), les serveurs MCP, et vos outils personnalisés : Claude émet la demande, votre code l’exécute et renvoie le résultat à la session |
| Mémoire | Un magasin de mémoire monté comme un répertoire dans le bac à sable ; chaque modification crée une version immuable |
| Résultat attendu (outcome) | Une grille en Markdown, notée par un évaluateur dans une fenêtre de contexte séparée ; l’agent itère jusqu’à la satisfaire |
| Plusieurs agents | Un coordinateur délègue à d’autres agents, qui partagent le bac à sable et les fichiers, chacun dans son propre fil de conversation |
| Déploiements planifiés | Des sessions lancées d’elles-mêmes selon un horaire cron |
La règle d’or : l’agent une fois, la session à chaque exécution
Un agent est une configuration enregistrée et versionnée. Chaque modification crée une nouvelle version. Une session lancée avec le seul identifiant de l’agent prend sa dernière version, et vous pouvez aussi l’attacher à une version précise. Vous pouvez donc faire évoluer l’agent sans casser les sessions en cours, déployer une nouvelle version progressivement, ou comparer deux versions. Cela ne fonctionne que si vous créez l’agent une seule fois, en stockant son identifiant, puis lancez une session à chaque exécution. Créer un nouvel agent à chaque requête est l’erreur classique : vous accumulez des agents orphelins et payez le temps de création pour rien. Pour changer le comportement, on met à jour l’agent existant.
Quand choisir les agents gérés
D’après la documentation, pour les charges de travail qui demandent :
- une exécution longue : des tâches de plusieurs minutes ou heures, avec de nombreux appels d’outils ;
- une infrastructure cloud : des bacs à sable sécurisés, avec des paquets préinstallés et un accès réseau ;
- une exécution hébergée chez vous, pour des raisons de conformité ou de résidence des données ;
- un minimum d’infrastructure : ni boucle d’agent, ni bac à sable, ni couche d’exécution des outils à construire ;
- des sessions avec état : un système de fichiers et un historique qui persistent d’une interaction à l’autre ;
- une exécution planifiée, avec les déploiements planifiés.
Les garde-fous
- Les permissions d’outils : chaque outil peut être autorisé d’office (
always_allow), soumis à votre confirmation (always_ask), ou évalué par le serveur (auto), qui l’exécute, le refuse ou attend votre accord. Par défaut, les outils intégrés sont autorisés d’office et les outils MCP demandent confirmation. - Les coffres (vaults) : les identifiants (jetons OAuth des serveurs MCP, clés pour des outils en ligne de commande) sont enregistrés une fois et rattachés aux sessions. Une variable d’environnement d’un coffre n’apparaît dans le bac à sable que sous forme d’espace réservé, remplacé par le vrai secret à la sortie : l’agent ne voit jamais sa valeur.
- Le réseau : un environnement peut limiter les hôtes joignables.
- L’archivage : archiver un agent est définitif ; il passe en lecture seule, les sessions en cours continuent, mais aucune nouvelle session ne peut s’y rattacher. Un environnement archivé passe aussi en lecture seule, et une session archivée garde son historique mais ne reçoit plus d’événements.
À vous de jouer
Choisir son terrain. Pour deux projets que vous connaissez, décidez s’ils relèvent de la Messages API ou des agents gérés : durée de la tâche, besoin d’un environnement d’exécution, besoin de reprendre plus tard. Pour celui qui va aux agents gérés, listez les briques des trois exemples dont il aurait besoin, et notez la raison principale de chaque choix.
Sources officielles : What are managed agents? (Claude Academy) · Claude Managed Agents overview · Define your agent · Permission policies · Vaults · Agent SDK overview (comparaison des approches)
Points clés à retenir
- Les agents gérés : Anthropic fait tourner la boucle et héberge un bac à sable par session
- Quatre concepts (agent, environnement, session, événements) et des briques : outils personnalisés, MCP, mémoire, résultat attendu, plusieurs agents, planification
- L’agent se crée une fois (versionné), la session se lance à chaque exécution
- Permissions d’outils, coffres pour les identifiants, réseau limité ; archiver un agent est définitif