Un exemple de départ : 400 contrats à relire avant vendredi
Une PME de services a reçu l'ordre de son directeur financier : relire 400 contrats fournisseurs avant vendredi pour repérer trois choses, les clauses de reconduction tacite, les pénalités de résiliation et la juridiction applicable. Le réflexe de beaucoup de dirigeants est d'ouvrir une conversation Claude, de déposer les fichiers et de demander le tableau final. Ça marche pour 5 contrats. Sur 400, le contexte se sature, les réponses se dégradent au fil de la conversation, et on ne sait plus quel contrat a produit quelle ligne du tableau. Aucune trace, aucun moyen de relancer proprement les cas douteux.
Ce problème est exactement celui que les workflows dynamiques de Claude Managed Agents cherchent à résoudre. Cet article explique ce que c'est, quand ça vaut le coup, et comment cadrer un premier pilote. Si tu débutes avec Claude, commence plutôt par le guide complet pour apprendre Claude, puis reviens ici.
Ce que sont les Managed Agents et un workflow dynamique
Un Managed Agent est un agent hébergé et exécuté par Anthropic via son API : il reçoit une tâche, utilise ses outils et travaille jusqu'au résultat, sans que tu aies à gérer toi-même la boucle d'exécution ni l'infrastructure. Depuis le 9 octobre 2026, une bêta ajoute les workflows dynamiques : un agent écrit lui-même un programme qui lance de nombreux sous-agents par phases et combine leurs résultats, et le serveur exécute ce programme en arrière-plan. Le plan n'est donc pas figé à l'avance par toi, c'est l'orchestrateur (l'agent qui découpe le lot, distribue les tâches et agrège les retours) qui le construit à l'exécution.
Pour situer l'approche, voici les trois façons de traiter un lot de documents :
| Approche | Contrôle | Vitesse | Coût | Cas d'usage |
|---|---|---|---|---|
| Prompt unique | Faible, tout dans un seul fil | Rapide pour 5 à 10 documents | Bas | Petit lot, exploration |
| Script séquentiel (boucle sur l'API) | Élevé, tu codes chaque étape | Lente : un document après l'autre | Proportionnel au volume | Traitement répétitif et stable |
| Workflow dynamique | Moyen : tu fixes le cadre, l'orchestrateur adapte | Rapide : sous-agents en parallèle | Proportionnel au volume, plus les passes de contrôle | Gros lot de documents hétérogènes |
Précision importante : la fonctionnalité est en bêta et ses limites évoluent. Vérifie toujours la documentation Anthropic à jour avant de t'engager sur un chiffrage. Pour comprendre le socle technique, regarde aussi l'API Anthropic.
Pourquoi le parallèle change la donne sur un gros volume
Trois effets concrets, dans cet ordre d'importance pour un dirigeant.
Le premier est le délai. Dans une boucle séquentielle, le temps total est la somme des temps de chaque document. En parallèle, il tend vers le temps du document le plus long, plus le temps d'agrégation. La documentation indique une limite de 64 threads actifs en même temps dans un run : on ne lance donc pas 400 agents simultanément, mais par vagues de 64 au plus. Sur nos 400 contrats, si un sous-agent met 1 minute par contrat, la boucle séquentielle demande environ 6 heures et demie, contre une dizaine de minutes en vagues de 64. C'est une estimation de raisonnement, pas une mesure : seul un pilote te donnera le vrai chiffre sur tes documents.
Le deuxième effet est la qualité. Chaque sous-agent reçoit une consigne courte et un seul contrat, donc un contexte propre. Il n'hérite pas des 300 pages lues avant lui, ce qui limite la dérive qu'on observe dans un fil unique très long.
Le troisième effet est l'isolation des erreurs. Un PDF scanné illisible fait échouer un sous-agent, pas le lot entier. Tu récupères la liste des échecs à part et tu les retraites ou les confies à un humain.
Une limite à connaître pour ne pas se tromper : la documentation fixe 1 000 agents lancés au maximum sur la vie d'un run, et une durée de vie de 24 heures par défaut. Au-delà de 1 000 documents, il faut découper en plusieurs runs.
Les 4 briques d'un workflow qui tient en production
Les quatre briques ne s'empilent pas au hasard : ce que tu décides pour l'une contraint les autres.
1. L'orchestrateur. Il lit la liste des 400 contrats, les découpe en lots, lance les sous-agents et assemble les résultats. Sa consigne tient en peu de lignes : « Pour chaque fichier du dossier, lance un sous-agent avec la consigne contrat. Collecte les sorties JSON. Écris un tableau final et une liste séparée des fichiers en échec. » Dans la bêta, l'activation passe par le champ multiagent de l'agent, avec les workflows à l'état activé, et l'avancement se suit via les événements workflow_run.* du flux de session.
2. Les sous-agents. Un sous-agent, c'est un agent qui traite un seul document avec une consigne courte et rend une sortie dans un format strict. Exemple : « Lis ce contrat. Renvoie uniquement un JSON avec les champs reconduction_tacite (oui/non), preavis_jours, penalite_resiliation, juridiction, et pour chacun la phrase du contrat qui le justifie. Si une information est absente, écris null. » Ce format imposé conditionne tout le reste : si chaque sous-agent invente sa propre structure, l'orchestrateur ne peut rien agréger.
3. Les outils. Ce sont les accès dont les agents ont besoin : lire les fichiers, interroger tes données, écrire dans ton CRM ou ton tableur. Pour relier ces outils à Claude, le standard est le MCP (Model Context Protocol, un protocole ouvert qui sert à brancher un modèle sur des outils tiers). Détails sur brancher vos outils et vos données via MCP. Choisis les outils avant de rédiger les consignes : un sous-agent qui doit écrire directement dans le CRM n'aura pas la même consigne qu'un sous-agent qui rend seulement du JSON.
4. Le contrôle qualité. Deux options, cumulables. Un agent relecteur reçoit le contrat et la sortie JSON et répond « cohérent » ou « à vérifier » avec la raison. Ou bien un humain contrôle un échantillon, par exemple 1 contrat sur 10, et tout contrat marqué « à vérifier ». Fixe les règles de rejet avant le lancement : une citation absente du contrat, un champ obligatoire vide, une juridiction non reconnue. Le relecteur ne sert à rien si les règles ne sont pas écrites.
Trois cas d'usage où ça vaut le coup, et un où ça ne vaut pas
Relecture de contrats. Volume rentable : à partir d'une cinquantaine de contrats de même nature, quand les clauses à repérer sont identiques d'un document à l'autre. Sortie attendue : un JSON par contrat avec citation à l'appui. Risque principal : un contrat atypique dont la clause n'a pas la forme attendue, qui sort « null » alors qu'elle existe sous une autre formulation. Le contrôle qualité sert à ça.
Pré-qualification de candidatures ou d'appels d'offres. Volume rentable : à partir de quelques dizaines de dossiers pour un même poste ou un même marché. Sortie attendue : une grille de critères remplie par dossier, avec le passage du document qui justifie chaque case. Risque principal : l'agent applique les critères de façon trop rigide ou introduit un biais. La décision finale reste humaine, et la grille doit être validée à la main sur quelques dossiers avant le lot.
Extraction de données de factures hétérogènes. Volume rentable : dès que les factures arrivent dans des formats différents (PDF natifs, scans, mises en page de fournisseurs variés). Sortie attendue : montant HT, TVA, date, numéro, fournisseur, rendus dans un format unique. Risque principal : les montants. Prévois une règle de rejet automatique si la somme HT plus TVA ne tombe pas sur le TTC.
Le contre-exemple honnête : un lot de 15 contrats à fort enjeu, par exemple pour une acquisition. Ici, le temps gagné par le parallèle est marginal et chaque contrat mérite une lecture attentive d'un juriste. Une seule conversation Claude assistée par un humain reste plus sûre et moins chère à mettre en place. Le parallèle se justifie par le volume, pas par l'enjeu.
Si tu veux voir comment ces briques s'assemblent dans un projet d'ensemble, la page pilier construire des agents IA autonomes avec Claude donne la vue d'ensemble. Pour la partie sécurité, l'article sécuriser un agent Claude est un bon complément.
Combien ça coûte et comment cadrer un premier pilote
Je ne donne pas de tarif figé : les prix changent, et la grille en vigueur se lit sur le site d'Anthropic. Ce qui dure, c'est la méthode d'estimation. Côté documentation, un run n'a pas de prix propre : les tokens des agents sont facturés au tarif de chaque modèle, et Managed Agents facture en plus le temps de session à 0,08 $ par heure d'exécution. La doc conseille aussi de fixer un budget de session.
Formule de départ : nombre de documents x tokens moyens par document x nombre de passes (extraction, puis relecture) x tarif du modèle choisi par million de tokens, auquel on ajoute le temps de session. Si tu travailles par exemple avec Claude Haiku 5.5 pour l'extraction (0,10 $ le million de tokens en entrée jusqu'à 100k tokens par prompt, 0,50 $ en sortie) et un modèle plus fort pour la relecture, tu peux chiffrer les deux passes séparément. Fais le calcul avec la grille du jour, pas avec ces chiffres figés dans un article.
Pilote en quatre étapes :
- Choisis 30 documents représentatifs de ton lot, pas les 30 plus simples.
- Écris à la main le résultat attendu pour 10 d'entre eux : c'est ta référence.
- Lance le workflow sur les 30 avec un budget de session plafonné.
- Compare avec ta référence : taux de concordance, taux de rejet, documents en échec.
Fixe ton critère de décision avant de lancer, pas après avoir vu les résultats. Par exemple : au moins 90 % de concordance avec la relecture humaine, seuil à relever si l'enjeu est élevé. Attention à un point de la bêta : aucune étape d'approbation n'a lieu avant le lancement d'un run, donc le plafond de budget est ton seul garde-fou avant exécution.
Points de vigilance : vérifie ce que tu as le droit d'envoyer à une API tierce (contrats, CV, données personnelles), journalise ce que chaque sous-agent a décidé et pourquoi, et garde une validation humaine sur tous les cas à fort enjeu.
Passer de l'idée au premier agent en production
La prochaine étape concrète tient en un mot : pilote. Trente documents, dix résultats écrits à la main, un seuil de réussite fixé à l'avance. Rien d'autre à décider cette semaine. Cet article ne remplace pas la lecture de la documentation technique à jour avant de coder : la fonctionnalité est en bêta, ses limites peuvent bouger. Pour être accompagné sur la mise en place de tes propres agents, de la conception au déploiement sécurisé, c'est ici : Piloter vos agents autonomes.