Claude Code Workflows Dynamiques : Exécution de Centaines de Sous-Agents Parallèles avec Opus 4.8

Claude Opus 4.8 a introduit une fonctionnalité importante pour Claude Code : les Flux de travail dynamiques. Dans une seule session, un agent d’orchestration peut lancer des centaines de sous-agents en parallèle pour traiter une tâche large et ramifiée : refactoriser plusieurs dizaines de fichiers, exécuter une grande matrice de tests ou comparer plusieurs pistes d’implémentation en même temps. Dans le terminal, cela ressemble à de la magie. En pratique, le mécanisme repose sur deux briques précises.

Essayez Apidog aujourd’hui

Ce guide explique comment fonctionnent réellement les Flux de travail dynamiques, quand les utiliser, et comment reproduire ce modèle d’orchestration avec l’API brute. Pour le contexte sur le modèle, consultez qu’est-ce que Claude Opus 4.8. Pour l’architecture d’agent, lisez aussi notre analyse de l’architecture du harnais d’agent Claude Code.

Ce que sont réellement les Flux de travail dynamiques

Dans Claude Code, les Flux de travail dynamiques apparaissent sous le mode ultracode dans le menu d’effort. Point important : ultracode n’est pas un nouveau niveau d’effort côté API.

C’est une combinaison de deux capacités déjà présentes dans Opus 4.8 :

1. Le niveau d’effort xhigh
2. Les messages système en cours de conversation

Ensemble, ces deux éléments donnent à l’orchestrateur :

• assez de profondeur de raisonnement pour planifier une tâche complexe ;
• la permission de lancer des agents de travail pendant l’exécution ;
• la capacité de fusionner les résultats dans la session principale.

Le reste relève surtout de l’implémentation spécifique à Claude Code.

Ingrédient 1 : l’effort xhigh

Le paramètre effort contrôle le nombre de tokens qu’Opus 4.8 peut utiliser pour produire une réponse, y compris les appels d’outils.

xhigh est le niveau recommandé par Anthropic pour :

• le codage long ;
• les tâches agentiques ;
• les exécutions de plus de 30 minutes ;
• les budgets de tokens de plusieurs millions.

Pour un Flux de travail dynamique, cette profondeur est essentielle. L’orchestrateur doit :

1. analyser la tâche globale ;
2. la découper en unités indépendantes ;
3. décider combien d’agents lancer ;
4. suivre leurs résultats ;
5. fusionner les sorties dans une réponse cohérente.

Avec un effort plus faible, le modèle tend à réduire la portée, faire moins d’appels d’outils et limiter la planification. C’est souvent l’inverse de ce que vous voulez pour une orchestration multi-agents.

Pour démarrer, utilisez un max_tokens élevé. Par exemple :

max_tokens=64000

64K est un bon point de départ pour donner à l’orchestrateur assez de marge de raisonnement et de coordination.

Ingrédient 2 : les messages système en cours de conversation

La deuxième brique est la prise en charge des messages système en cours de conversation dans l’API Messages.

Avant Opus 4.8, l’invite système était généralement fixée au début de la conversation. Avec Opus 4.8, vous pouvez insérer une entrée système au milieu du tableau messages pour ajouter de nouvelles instructions ou permissions pendant l’exécution.

Ce mécanisme permet à l’orchestrateur de recevoir une permission comme :

Tu peux maintenant distribuer cette tâche à plusieurs agents de travail indépendants.

sans avoir à tout décider au début de la conversation.

Anthropic documente cette capacité dans les messages système en cours de conversation.

Conséquence pratique : un agent peut acquérir de nouvelles capacités en cours d’exécution, selon ce qu’il découvre pendant la tâche.

Activer les Flux de travail dynamiques dans Claude Code

Dans Claude Code, les Flux de travail dynamiques sont accessibles via l’option ultracode du menu d’effort.

Cette option :

• active l’effort xhigh ;
• donne à la session l’autorisation de lancer des sous-agents parallèles ;
• utilise des messages système en cours de conversation pour piloter l’orchestration.

Une fois activé, décrivez une tâche large, par exemple :

Refactorise le module d’authentification dans tous les services.
Identifie les fichiers concernés, propose un plan, exécute les changements par lots,
puis valide les tests associés.

Claude Code peut alors :

• planifier la tâche ;
• découper le travail en sous-tâches ;
• lancer des agents de travail en parallèle ;
• limiter chaque agent à une partie précise du travail ;
• récupérer et fusionner les résultats dans la session principale.

Si vous utilisez Claude Code avec un plan, notre guide de configuration du SDK d’agent Claude avec plan Claude couvre la configuration autour de cette approche.

Quand utiliser les Flux de travail dynamiques

Les Flux de travail dynamiques sont utiles quand la tâche est large, ramifiée et parallélisable.

Bons cas d’usage :

• refactoriser un motif sur de nombreux fichiers ;
• générer et exécuter une matrice de tests ;
• explorer plusieurs approches d’implémentation en parallèle ;
• analyser une grande base de code module par module ;
• comparer plusieurs solutions avant de fusionner la meilleure.

Exemple de tâche adaptée :

Analyse tous les modules de paiement.
Pour chaque module, identifie les dépendances obsolètes,
les tests manquants et les risques de régression.
Retourne une synthèse consolidée avec les actions prioritaires.

Ici, chaque agent peut traiter un module différent.

Quand éviter les Flux de travail dynamiques

Évitez ce mode pour les tâches :

• étroites ;
• strictement séquentielles ;
• limitées à un seul fichier ;
• dépendantes d’un ordre d’exécution précis.

Mauvais cas d’usage :

Renomme cette variable dans ce fichier.

Lancer des dizaines ou centaines de sous-agents pour une modification locale brûle des tokens sans bénéfice. Les agents parallèles n’aident pas non plus quand chaque étape dépend obligatoirement de la précédente.

Le coût est réel : des centaines de sous-agents en xhigh peuvent représenter des millions de tokens. Utilisez ce modèle uniquement lorsque la structure du travail justifie le parallélisme.

Construire la même orchestration via l’API

Vous n’avez pas besoin de Claude Code pour construire ce type d’orchestration. Les mêmes ingrédients sont disponibles dans l’API Messages brute.

Anthropic fournit un exemple dans construire un mode d’orchestration.

La structure générale est la suivante :

1. Lancer un appel d’orchestrateur en xhigh
2. Demander à l’orchestrateur de planifier la tâche
3. Injecter un message système en cours de conversation pour autoriser la distribution
4. Lancer des agents de travail en parallèle
5. Collecter les résultats
6. Renvoyer les résultats à l’orchestrateur pour fusion

Exemple minimal :

import anthropic

client = anthropic.Anthropic()

orchestrator = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    thinking={"type": "adaptive"},
    messages=[
        {
            "role": "user",
            "content": "Plan a refactor of the auth module across all 14 services."
        },
    ],
)

Ensuite, chaque agent de travail peut être un appel messages.create() distinct, exécuté en parallèle par votre application.

Pour une sous-tâche étroite, vous n’avez pas forcément besoin de xhigh. Vous pouvez réduire l’effort :

worker = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=12000,
    output_config={"effort": "medium"},
    messages=[
        {
            "role": "user",
            "content": "Refactor only service-auth-api. Do not modify other services."
        },
    ],
)

Si vous comparez cette approche avec une infrastructure d’agents hébergée, consultez le guide agents gérés vs SDK d’agent.

Exemple de boucle d’orchestration

Voici une structure simplifiée côté application :

from concurrent.futures import ThreadPoolExecutor
import anthropic

client = anthropic.Anthropic()

tasks = [
    "Analyse le service auth-api",
    "Analyse le service billing-api",
    "Analyse le service user-api",
]

def run_worker(task):
    return client.messages.create(
        model="claude-opus-4-8",
        max_tokens=12000,
        output_config={"effort": "medium"},
        messages=[
            {
                "role": "user",
                "content": task
            }
        ],
    )

with ThreadPoolExecutor(max_workers=3) as executor:
    worker_results = list(executor.map(run_worker, tasks))

merge_prompt = {
    "role": "user",
    "content": f"""
Fusionne ces résultats d'agents de travail en un plan d'action unique :

{worker_results}
"""
}

merged = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=32000,
    output_config={"effort": "xhigh"},
    messages=[merge_prompt],
)

Cette version reste volontairement simple. En production, ajoutez au minimum :

• un identifiant par sous-tâche ;
• un schéma de sortie attendu ;
• des timeouts ;
• des retries ;
• une limite de concurrence ;
• un plafond de tokens par agent.

Coût et contrôle

Les sous-agents parallèles multiplient rapidement la consommation de tokens.

Un Flux de travail dynamique qui lance 200 agents, chacun avec plusieurs dizaines de milliers de tokens, peut coûter cher. Pour garder le contrôle, appliquez ces règles :

• Délimitez précisément chaque agent de travail
  
  Donnez-lui un module, un fichier, une suite de tests ou une hypothèse précise.

• Réduisez l’effort des agents quand c’est possible
  
  Gardez xhigh pour l’orchestrateur. Utilisez medium ou low pour les sous-tâches simples.

• Fixez un max_tokens par agent
  
  Empêchez un agent isolé de consommer une part disproportionnée du budget.

• Mettez en cache le contexte partagé
  
  Évitez de repayer le même contexte système au tarif plein pour chaque agent.

• Limitez la concurrence
  
  Ne lancez pas 200 appels si 20 suffisent pour saturer votre pipeline.

La ventilation des prix d’Opus 4.8 détaille l’impact des niveaux d’effort et de la mise en cache.

En résumé : le parallélisme doit être un choix explicite, pas un réflexe.

Tester votre orchestration avec Apidog

Lorsque vous construisez l’orchestration via l’API, la partie difficile à déboguer est le fan-out :

• chaque agent reçoit-il le bon contexte ?
• la sous-tâche est-elle assez limitée ?
• la réponse respecte-t-elle le format attendu ?
• l’étape de fusion sait-elle consommer les résultats ?
• le message système en cours de conversation est-il bien transmis ?

Vous ne voulez pas découvrir ces erreurs après 200 appels réels.

Apidog vous permet de tester chaque composant séparément :

• enregistrer la requête de l’orchestrateur ;
• inspecter le plan de décomposition avant de lancer les agents ;
• simuler le point d’accès des agents de travail ;
• tester la logique de distribution sans consommer de tokens ;
• ajouter des assertions sur la forme des réponses ;
• rejouer un appel d’agent avec différents niveaux d’effort.

Pour démarrer :

1. Créez une requête vers https://api.anthropic.com/v1/messages
2. Configurez la requête orchestrateur avec effort: xhigh
3. Créez une requête agent de travail avec un contexte réduit
4. Ajoutez des assertions sur la structure attendue
5. Testez la fusion avec des réponses simulées
6. Passez ensuite aux appels réels

Le guide de l’API Opus 4.8 contient la requête de base pour commencer.

FAQ

Que sont les Flux de travail dynamiques dans Claude Code ?

Une fonctionnalité qui permet à une session de lancer des sous-agents parallèles pour gérer des tâches larges et ramifiées. Elle repose sur l’effort xhigh et les messages système en cours de conversation dans Opus 4.8.

Ultracode est-il un niveau d’effort distinct ?

Non. Ultracode est le nom utilisé dans Claude Code pour combiner l’effort xhigh avec une autorisation de lancer des flux de travail multi-agents. Les niveaux d’effort de l’API restent low, medium, high, xhigh et max.

Que sont les messages système en cours de conversation ?

Une capacité de l’API Messages qui permet d’insérer une entrée système au milieu d’une conversation pour ajouter des instructions ou permissions pendant l’exécution.

Puis-je construire des Flux de travail dynamiques sans Claude Code ?

Oui. Utilisez l’effort xhigh et les messages système en cours de conversation avec l’API Messages brute. Votre application peut ensuite lancer les agents de travail en parallèle et renvoyer leurs résultats à l’orchestrateur.

Les Flux de travail dynamiques coûtent-ils cher ?

Oui, ils peuvent. Des centaines de sous-agents en xhigh peuvent représenter des millions de tokens. Limitez la portée, réduisez l’effort des sous-agents quand possible, plafonnez max_tokens et mettez en cache le contexte partagé.

Quand dois-je éviter les Flux de travail dynamiques ?

Pour les tâches petites, locales ou strictement séquentielles. Si chaque étape dépend de la précédente, les agents parallèles n’apportent pas de valeur et augmentent seulement le coût.