Computer use, agents autonomes et dynamic workflows

Pourquoi ce module

Jour 5 du tronc commun — le sommet. On passe de l'agent qui agit avec vous à l'agent qui travaille à votre place : computer use, agents autonomes (boucles AFK, mode headless), Agent view pour piloter plusieurs sessions, et les dynamic workflows qui orchestrent des centaines de sous-agents. La journée se conclut par le projet final déployé.

🎯 C'est ici que vivent les dynamic workflows que vous avez peut-être croisés : la version industrielle de l'orchestration de sous-agents vue en J4.

Objectifs pédagogiques

À l'issue de ce module, vous serez capable de :

1. Utiliser le computer use et le Chrome DevTools MCP pour fermer la boucle sur ce qu'une GUI seule permet de vérifier
2. Lancer des agents autonomes (mode headless claude -p, boucles AFK, human-in-the-loop)
3. Maîtriser le system prompt en headless (--system-prompt, --append-system-prompt) et cadrer une tâche longue par ses critères de sortie plutôt que par sa procédure
4. Piloter plusieurs sessions avec l'Agent view (claude agents)
5. Comprendre et déclencher des dynamic workflows (centaines de sous-agents en parallèle)
6. Concevoir et déployer un assistant métier complet (projet final)

Plan détaillé

1. Computer use : capacités et limites
2. Chrome DevTools MCP
3. Agents autonomes : headless, AFK, human-in-the-loop
4. Piloter le system prompt : --system-prompt et --append-system-prompt
5. /goal : travailler jusqu'à une condition de complétion
6. Cadrer une tâche longue : sous-spécifier, mais rendre vérifiable
7. Agent view : piloter des sessions en arrière-plan
8. Worktrees : sessions parallèles isolées
9. Dynamic workflows : orchestration à grande échelle
10. Claude Code Artifacts (bêta Team/Enterprise)
11. Auto mode
12. Projet final : conception → déploiement

Computer use : capacités et limites

Le computer use donne à Claude la capacité de voir l'écran et d'agir (clic, saisie, scroll) — utile quand seule une interface graphique permet de valider un résultat. Disponible en research preview dans le CLI ; à exécuter dans un environnement isolé (VM/conteneur, réseau maîtrisé).

Pour le web, le Chrome DevTools MCP expose 30+ outils (navigate, click, fill, screenshot, evaluate, lighthouse, traces de performance) : automatiser une saisie complexe (portails clients, INPI/OPCO…) ou auditer un site (lighthouse + console + réseau + a11y).

⚠️ Sécurité : un agent qui pilote un navigateur peut être la cible d'une prompt injection indirecte (page malveillante). Sandbox, permissions restreintes, et human-in-the-loop sur les actions sensibles.

🆕 Claude in Chrome est GA (v2.1.198, juillet 2026). L'extension Claude in Chrome — Claude qui pilote votre navigateur (onglets, formulaires, sessions authentifiées) — sort de preview et devient généralement disponible. Positionnement vs Chrome DevTools MCP : l'extension agit dans votre navigateur du quotidien (parcours authentifiés, apps SaaS), le MCP DevTools pilote une instance dédiée avec l'outillage de debug (console, réseau, lighthouse). Les garde-fous prompt-injection ci-dessus s'appliquent aux deux.

Agents autonomes : headless, AFK, human-in-the-loop

• Mode headless : claude -p "objectif" exécute une tâche sans UI interactive (idéal CI/scripts).
• Boucle AFK (Away From Keyboard) : on fixe un objectif de haut niveau et l'agent itère seul — exécute, auto-évalue, recommence.
• Human-in-the-loop : validation humaine aux points critiques (vs full autonomous en environnement jetable).

Piloter le system prompt : --system-prompt et --append-system-prompt

En interactif, on cadre Claude par le CLAUDE.md et les règles (J1). En headless, on dispose d'un levier plus direct : remplacer ou compléter le system prompt au lancement, par invocation.

# Un agent de triage aux règles figées, indépendant du CLAUDE.md du dépôt
claude -p "Classe cette issue" \
  --append-system-prompt "Réponds uniquement par un JSON {severite, equipe}."

Deux points de vigilance. D'abord, --system-prompt remplace : vous perdez tout le prompting outillage de Claude Code, ce qui est rarement l'intention — --append-system-prompt est le défaut raisonnable. Ensuite, les variantes -file existent mais ne sont pas listées dans claude --help (vérifié sur v2.1.220, où elles n'apparaissent que dans la description de --safe-mode) : elles fonctionnent, mais ne sont pas contractuelles.

💡 Le lien avec le prompt caching (J1). --exclude-dynamic-system-prompt-sections sort du system prompt tout ce qui varie d'une machine à l'autre. Résultat : le préfixe redevient identique entre utilisateurs et entre runs, donc cacheable. Sur une flotte de CI qui lance des centaines de claude -p par jour, c'est un gain direct. Sans effet si vous passez --system-prompt (le prompt par défaut n'est alors plus utilisé).

/goal : travailler jusqu'à une condition

La commande /goal maintient Claude au travail entre les tours jusqu'à ce qu'une condition de complétion soit remplie — au lieu de s'arrêter après une réponse. Parfait pour « ne t'arrête pas tant que les tests ne passent pas / tant que l'objectif n'est pas atteint ».

Cadrer une tâche longue : sous-spécifier, mais rendre vérifiable

Le mode d'échec le plus courant sur les tâches longues n'est pas le manque de consignes — c'est l'excès. « Fais ça, mais de cette façon, puis de cette façon, et surtout comme ceci » : on décrit la procédure qu'on avait en tête au lieu du résultat attendu. Sur les modèles récents, c'est activement contre-productif : chaque contrainte de méthode ferme une voie que le modèle aurait peut-être mieux empruntée, et la sur-spécification transforme un agent capable en exécutant bridé.

Le cadrage qui fonctionne tient en trois éléments — et la procédure n'en fait pas partie :

1. La tâche — le résultat visé, pas les étapes pour y arriver
2. Les garde-fous — le périmètre interdit (fichiers à ne pas toucher, dépendances à ne pas ajouter, API à ne pas casser)
3. Les critères de sortie — à quoi on reconnaît que c'est fini, de façon vérifiable par Claude lui-même

Ce troisième point est celui que l'on rate le plus souvent, et c'est celui qui décide du succès. Une boucle autonome sans oracle dérive : de petits écarts se composent, et au bout de plusieurs heures on peut être très loin de la cible sans que rien ne l'ait signalé. Une suite de tests, un linter, un script de vérification, un schéma à valider — c'est ce qui referme la boucle et permet à l'agent de se corriger seul. C'est la boucle de feedback de J1, appliquée à l'échelle de la journée plutôt que du tour de conversation.

🎯 La règle empirique. Donnez à Claude une tâche légèrement trop dure, et rendez-lui possible de vérifier son propre travail. C'est le conseil que Boris Cherny désigne comme « la seule chose que les gens ne font pas bien » — et il explique pourquoi les mêmes boucles autonomes réussissent spectaculairement chez les uns et partent en vrille chez les autres : ce n'est pas le prompt qui diffère, c'est l'oracle.

⚠️ Le corollaire économique. Les démonstrations de tâches à plusieurs jours viennent d'équipes au budget de tokens illimité. Une boucle autonome de quelques heures consomme déjà beaucoup ; sur facturation API, une expérience spéculative de plusieurs jours se chiffre très vite. Avant de lancer long, bornez : critère de sortie atteignable, et un point de contrôle humain qui coupe si la trajectoire diverge (voir waitingFor et les hooks Notification ci-dessous).

💰 Le garde-fou dur : --max-budget-usd. Un critère de sortie borne la trajectoire, pas la dépense — une boucle qui n'atteint jamais son oracle tourne indéfiniment. --max-budget-usd <montant> pose un plafond en dollars sur la session. Depuis la v2.1.217, il a de vraies dents : une fois le plafond atteint, les nouveaux sous-agents sont refusés et les agents en arrière-plan déjà lancés sont arrêtés — avant, ils continuaient à consommer hors du plafond. C'est le flag à mettre sur tout claude -p non surveillé, en CI comme en cron.

claude -p "Migre les tests vers Vitest" --max-budget-usd 5

Agent view : piloter des sessions en arrière-plan

Ouverte avec claude agents, l'Agent view est un écran pour toutes vos sessions en arrière-plan : ce qui tourne (Working), ce qui attend votre input (Needs input), ce qui est terminé (Completed). On dispatch de nouvelles sessions, on suit l'état d'un coup d'œil, et on n'intervient que quand une session le réclame. Chaque session en arrière-plan est une conversation Claude Code complète qui continue sans terminal attaché.

🔧 Pilotage scripté. claude agents --json expose l'état machine-lisible de vos sessions ; depuis v2.1.162, le champ waitingFor indique ce qui bloque une session (permission, input, dépendance) — utile pour un superviseur ou un dashboard qui relance/notifie sans surveiller l'écran.

🆕 Livraison de bout en bout (v2.1.198). Un background agent lancé depuis claude agents qui termine un travail de code dans un worktree commit, push et ouvre une draft PR tout seul, au lieu de s'arrêter pour demander. Couplé aux notifications (Notification hook : agent_needs_input / agent_completed), la boucle AFK devient : dispatch → travail isolé → PR prête à reviewer.

Worktrees : sessions parallèles isolées

Quand plusieurs sessions (ou sous-agents) travaillent en même temps sur le même repo, elles se marchent dessus : un git checkout de l'une casse le contexte de l'autre. La solution Git native, intégrée à Claude Code, ce sont les worktrees — des copies de travail isolées partageant le même historique .git.

• Claude Code gère ses propres worktrees ; EnterWorktree (depuis v2.1.157) permet de basculer entre worktrees gérés en cours de session, sans quitter ni perdre le fil.
• Au lancement, claude --worktree démarre directement dans un worktree isolé, et --tmux lui adosse une session tmux (panneaux natifs iTerm2 quand c'est possible, --tmux=classic pour du tmux traditionnel). Les bricolages historiques — plusieurs git clone du même dépôt, jonglage manuel de sessions tmux — sont devenus du outillage intégré.
• Chaque session/sous-agent travaille sur sa copie : pas de conflit de fichiers, pas de stash à jongler. Idéal pour lancer N tentatives parallèles d'une même tâche (puis garder la meilleure), ou paralléliser une migration fichier par fichier.

💡 C'est la brique qui rend les sous-agents parallèles (J4) et les dynamic workflows (ci-dessous) sûrs sur un repo réel : on isole les modifications concurrentes au lieu de les sérialiser.

Dynamic workflows : orchestration à grande échelle

Un dynamic workflow est un script JavaScript qui orchestre des sous-agents à grande échelle. Particularité : c'est Claude qui écrit le script pour la tâche que vous décrivez, puis un runtime l'exécute en arrière-plan — votre session reste réactive.

• Échelle : Anthropic annonce, à partir d'Opus 4.8, que « Claude peut planifier le travail puis lancer des centaines de sous-agents en parallèle dans une seule session ». C'est vrai du modèle — mais pas de ce que fait le harness par défaut : voir l'encadré ci-dessous, qui est le point le plus souvent mal compris de cette section.
• Déclenchement : le demander dans le prompt, activer /effort ultracode (Claude décide), ou lancer un workflow existant (ex. /deep-research) ou un workflow sauvegardé.
• Suivi : /workflows liste les workflows en cours et terminés et ouvre leur vue de progression.
• Disponibilité : Claude Code v2.1.154+, tous plans payants, API, Bedrock / Vertex / Foundry.

⚠️ « Des centaines d'agents » : ce que le modèle peut vs ce que l'outil fait. L'écart entre les deux s'est creusé à l'été 2026, et citer le chiffre marketing sans la nuance donne une fausse idée du coût comme du comportement réel :

Garde-fou	Défaut	Réglage	Depuis
Sous-agents simultanés	20	CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS	v2.1.217
Sous-agents par session (cumul)	200	CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION — /clear remet le compteur à zéro	v2.1.212
Appels WebSearch par session	200	CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION	v2.1.212
Taille visée d'un workflow	« medium » : viser < 15 agents	/config → Dynamic workflow size, ou la clé workflowSizeGuideline	v2.1.202 / v2.1.219

Donc : des centaines d'agents au fil d'une session, oui ; des centaines en même temps, non. Vingt tournent à un instant donné, les autres font la queue et démarrent quand une place se libère — un parallel() de 100 éléments se termine bien, il s'étale simplement. La guideline de taille, elle, est consultative : elle oriente le script que Claude écrit, elle ne coupe rien.

💡 La lecture pédagogique. Ces plafonds sont arrivés en réaction à un vrai mode d'échec : un seul message qui déclenche une délégation en cascade et brûle un budget en quelques minutes. C'est le pendant, côté fournisseur, du garde-fou que vous devez poser vous-même (--max-budget-usd, plus haut). Retenez le principe : une capacité d'orchestration non bornée n'est pas une fonctionnalité, c'est un incident en attente.

🆕 Régler la taille des workflows (v2.1.202, étendu en v2.1.219). /config → Dynamic workflow size fixe l'ampleur que Claude vise (small / medium / large / unrestricted). Depuis la v2.1.219, la même valeur se pose par fichier de settings via workflowSizeGuideline — donc en settings.json projet versionné, ou en managed settings pour une flotte ; la ligne disparaît alors de /config pour signaler qu'elle est imposée. Le défaut est medium (viser moins de 15 agents), et la taille active s'affiche dans la ligne de statut du workflow en cours.

// .claude/settings.json — borner l'ampleur des workflows pour toute l'équipe
{ "workflowSizeGuideline": "small" }

💡 Différence avec les sous-agents « simples » (J4) : ici Claude écrit le code d'orchestration (fan-out, étapes, vérification) et le pousse à l'échelle de dizaines à centaines d'agents — pour des migrations, audits ou recherches massives.

Claude Code Artifacts (beta Team/Enterprise)

Les Artifacts transforment le travail d'une session Claude Code en pages HTML web interactives et partageables — des walkthrough de PR, des dashboards filtrables, des explainers de système, ou des release checklists qui se remplissent toutes seules au fil de la session.

Cas d'usage :

• Dashboard : filtrer/trier les résultats d'un audit en temps réel
• Release checklist : se complète automatiquement à mesure que la CI passe
• PR walkthrough : explication interactive du code, diffs visuels
• Système explicateur : diagrammes, architecture, points de décision

🎯 Bêta Team/Enterprise — Artifacts est une fonctionnalité bêta disponible uniquement sur les plans payants Team et Enterprise (pas Free/Pro pour l'instant). L'accès s'étend progressivement. Chaque Artifact est accessible via une URL privée que vous contrôlez.

• Disponibilité : annoncé le 18 juin 2026, en bêta sur les plans Team/Enterprise (déploiement progressif ; pas encore Free/Pro)
• Trigger : demandez au prompt de créer un Artifact pour vos résultats, ou Claude l'en proposera automatiquement pour certaines tâches (audits, workflows, analyses)

Source : Anthropic brings Artifacts to Claude Code — VentureBeat (18 juin 2026).

Auto mode

Le Auto mode (disponible jusque sur le plan Pro, supporte Sonnet 4.6 et Sonnet 5) remplace les prompts de permission par des vérifications de sécurité en arrière-plan : les actions sûres passent, les risquées sont bloquées. Le compromis entre tout valider à la main et bypassPermissions.

Garde-fous de sécurité (v2.1.183 + v2.1.178) :

• ⛔ Les commandes git destructives (git reset --hard, git push --force, git checkout ., git clean -f, git branch -D) sont bloquées en Auto mode sauf demande explicite
• ⛔ Les destroys d'infrastructure (terraform destroy, pulumi destroy, cdk destroy) sont bloqués en Auto mode sauf demande explicite
• 🤖 Les spawns de sous-agents passent par un classifieur avant lancement (v2.1.178) : Claude Code évalue si le sous-agent est approprié pour la tâche avant de l'instancier
• 🔎 autoMode.classifyAllShell (v2.1.193) : route toutes les commandes Bash/PowerShell par le classifieur (pas seulement celles repérées comme risquées) — posture plus stricte pour les environnements sensibles
• 📝 Les raisons de refus sont désormais écrites dans le transcript, le toast de refus et les « refus récents » de /permissions (v2.1.193) — on voit pourquoi une action a été bloquée

Ces garde-fous visent à éviter les destructions involontaires ou l'orchestration non-intentionnelle en environnement réel, tout en gardant Auto mode réactif pour les tâches exploratoires, de test et d'implémentation.

🆕 Auto mode en entreprise : trois changements de juillet 2026.

1. Plus d'opt-in sur les clouds (v2.1.207) : la variable CLAUDE_CODE_ENABLE_AUTO_MODE n'est plus nécessaire sur Bedrock, Vertex AI et Foundry. Auto mode y est disponible d'emblée ; on le coupe par le réglage disableAutoMode. Inversion de posture à connaître si votre gouvernance supposait que le mode était inaccessible par défaut.
2. autoMode n'est plus lu depuis .claude/settings.local.json (v2.1.207) — c'est-à-dire depuis un fichier résident du dépôt. Il faut le poser dans ~/.claude/settings.json. La logique est saine et vaut d'être expliquée en formation : un dépôt cloné ne doit pas pouvoir décider du niveau d'autonomie de votre agent. Même famille de raisonnement que le durcissement .mcp.json vu en J4.
3. claude auto-mode reset (v2.1.212) restaure la configuration par défaut, avec confirmation (--yes pour la sauter). Utile après une session d'expérimentation, ou dans un script de remise en état de poste.

Détail d'implémentation intéressant : depuis la v2.1.210, le classifieur qui arbitre les commandes tourne par défaut sur Sonnet 5 pour les sessions externes, validé à la première requête et figé pour la session. Autrement dit, votre garde-fou de permissions est lui-même un appel LLM — avec son coût, sa latence et son taux d'erreur. À garder en tête quand on raisonne sécurité : ce n'est pas une règle déterministe.

Projet final : conception → déploiement

L'après-midi est dédié à un assistant métier complet :

1. Conception : besoin → spécification → architecture (Skills + MCP + Sub-agents + Hooks).
2. Implémentation guidée : CLAUDE.md projet + 1 skill custom + 1 serveur MCP + 2 sous-agents + hooks sécurité + observabilité.
3. Production-ready : rate limit, retry/backoff, error handling, fallback si API down.
4. Déploiement : tests E2E, scénarios bout-en-bout, runbook incident.
5. Soutenance : architecture + démo live + métriques d'observabilité.

Atelier / Projet final

Livrable : un assistant métier déployé mobilisant l'ensemble du cursus — settings/permissions (J1), hooks/CI (J2), skill + SDK + vision (J3), MCP + sous-agents + observabilité (J4), et au moins un mode autonome (boucle AFK, /goal, ou dynamic workflow) (J5). Documentation : README, garde-fous, runbook.

Pour aller plus loin

• 📖 Claude Code — Dynamic workflows
• 📖 Claude Code — Agent view
• 📖 Computer use (Anthropic)
• 🎯 Tronc commun : J4 (sous-agents) ← fin du parcours · approfondissements : M13 (Cowork), M15 (pipeline commercial agentique)