Orchestration multi-agents

Fan-out parallèle vs pipeline

Orchestrer plusieurs agents, c'est choisir une topologie. Les deux primitives :

• Parallèle (fan-out) : lancer N agents en même temps sur des tâches indépendantes, attendre tout le monde (une barrière), puis agréger. A utiliser quand vous avez besoin de tous les résultats ensemble (déduplication globale, compte total).
• Pipeline : chaque élément traverse toutes les étapes de façon indépendante, sans barrière entre les étapes. L'élément A peut être à l'étape 3 pendant que B est encore à l'étape 1. Le choix par défaut pour un travail multi-étapes : le temps total est celui de la chaîne la plus lente, pas la somme des plus lents par étape.

Le piège classique : poser une barrière (parallèle) là où un pipeline suffirait, juste parce que le code semble plus propre. Une barrière n'est justifiée que si l'étape N a besoin du résultat complet de l'étape N-1 (fusion, déduplication, arrêt précoce si zéro). Sinon, pipeline.

Application concrète chez Pierre : ses audits SEO multi-langues (Eskimoz en 4 langues) sont des fan-outs ; un agent par langue, agrégation à la fin. Sa règle de modèle s'applique : Haiku/Sonnet pour les agents de masse, Opus pour la synthèse.

Vérification adversariale et panels de juges

Un agent qui détecte des bugs ou des résultats produit des sorties plausibles mais fausses (hallucination, encore). Le correctif d'orchestration : faire vérifier chaque résultat par d'autres agents avant de le conserver.

Patterns de qualité :

• Vérification adversariale : pour chaque résultat, lancer N agents sceptiques dont la consigne est de le réfuter. Ne conserver le résultat que si la majorité échoue à le réfuter. Élimine les faux positifs plausibles.
• Vérification multi-perspectives : si un résultat peut échouer de plusieurs façons, donner à chaque vérificateur un angle différent (exactitude, sécurité, performance, reproductibilité) plutôt que N copies identiques.
• Panel de juges : générer N solutions indépendantes sous des angles différents, les noter avec des juges en parallèle, synthétiser à partir du gagnant en greffant les meilleures idées des autres.
• Boucle jusqu'au tarissement : pour une recherche de taille inconnue (bugs, cas limites), relancer les détecteurs jusqu'à ce que K tours consécutifs ne renvoient rien de nouveau.

Principe directeur : la confiance naît de perspectives indépendantes qui se contredisent, non d'un agent seul et sûr de lui. C'est exactement l'esprit du réflexe de Pierre "reproduire via Playwright avant de corriger" : vérifier avant de croire, appliqué à l'échelle des agents.

Workflows : orchestration déterministe

Quand l'orchestration devient complexe (boucles, conditions, fan-out, budgets), on passe d'un agent improvisant à un workflow : un script qui orchestre les sous-agents de façon déterministe. Le flux de contrôle (qui s'exécute, quand, en parallèle ou en série) est codé, pas décidé par le modèle.

Blocs de construction typiques d'un moteur de workflow :

• agent(prompt, schema) : lancer un sous-agent et obtenir une sortie structurée validée.
• pipeline(items, ...stages) : faire passer chaque élément par les étapes sans barrière.
• parallel(thunks) : une barrière, tout en même temps.
• Boucles : loop-until-count (accumuler jusqu'à N), loop-until-dry (jusqu'à épuisement), loop-until-budget (jusqu'à un quota de tokens).

L'avantage par rapport à un seul grand agent : la structure (décomposer et couvrir en parallèle), la confiance (vérifier avant de conclure) et l'échelle (migrations ou audits qu'un contexte unique ne pourrait pas contenir). Vous restez dans la boucle : vous lisez chaque résultat avant de décider l'étape suivante. C'est le niveau le plus avancé, à réserver aux tâches qui le justifient vraiment, car il consomme beaucoup de tokens.

Barriere ou sans barriere

Dans un pipeline multi-agents (une chaîne d'agents IA où chaque agent effectue une tâche précise), vous devez décider à chaque transfert : l'étape suivante doit-elle attendre tous les résultats précédents, ou peut-elle démarrer dès qu'un seul résultat est disponible ? Cette décision s'appelle placer une barrière (ou non).

Une barrière est un point de synchronisation. Aucun agent en aval de la barrière ne démarre tant que tous les agents en amont n'ont pas terminé. C'est le bon choix quand l'étape suivante a réellement besoin d'une vue complète avant de pouvoir agir. Un fonctionnement sans barrière (également appelé streaming ou fan-in sans attente) laisse les résultats s'écouler un par un au fur et à mesure de leur arrivée, de sorte que le travail en aval commence immédiatement.

Posez-vous une seule question : "L'étape suivante peut-elle produire un résultat correct avec seulement des données partielles ?" Si oui, supprimez la barrière. Si non, ajoutez-en une. Une erreur dans un sens comme dans l'autre a un coût : une barrière inutile sérialise ce qui pourrait s'exécuter en parallèle, gaspillant du temps ; une barrière manquante corrompt les résultats car les agents en aval agissent sur des informations incomplètes.

• Utilisez une barrière quand vous agrégez des scores, fusionnez des jeux de données, rédigez un résumé final, ou pour toute opération qui n'est pas définie sur un sous-ensemble.
• Pas de barrière nécessaire quand chaque résultat est utilisable indépendamment : traduction de documents, redimensionnement d'images, envoi de notifications individuelles, ou diffusion de réponses partielles à un utilisateur.
• Les barrières partielles sont également valides : attendez les N premiers résultats (un quorum), puis continuez en ignorant les retardataires.

Boucler jusqu'à épuisement

Certaines tâches ont une frontière inconnue : vous ne savez pas combien d'éléments existent avant d'avoir fini de les collecter. La pagination, les analyses récursives de répertoires et le parcours itératif du web partagent cette structure. Le bon patron est une boucle à sec : répéter un cycle de recherche ou de récupération, collecter les nouveaux résultats, et s'arrêter uniquement lorsqu'un cycle ne renvoie rien de nouveau.

Dans un contexte multi-agents (où plusieurs instances de Claude se transmettent du travail), l'agent orchestrateur exécute la boucle et confie chaque lot aux agents travailleurs. L'orchestrateur gère un ensemble déjà vu, une collection dédupliquée de tout ce qui a déjà été traité, et compare chaque nouveau cycle à cet ensemble. Lorsque l'ensemble cesse de croître, la boucle se termine.

Claude Code prend en charge ce patron grâce aux commandes shell enchaînées et aux appels de sous-agents. Une boucle minimale dans une tâche Claude Code ressemble à ceci :

1. Exécuter une recherche ou un appel API et capturer la sortie.
2. Comparer la sortie à l'ensemble déjà vu.
3. Si la différence est non vide, ajouter les nouveaux éléments à l'ensemble déjà vu, envoyer le travail, puis revenir à l'étape 1.
4. Si la différence est vide, s'arrêter et faire un compte rendu.

Deux protections sont obligatoires : un plafond de cycles (par exemple, 50 itérations) pour éviter les boucles infinies causées par des bugs ou des comportements imprévus de l'API, et des travailleurs idempotents (des travailleurs qui produisent le même résultat s'ils traitent accidentellement deux fois le même élément). Sans ces protections, une boucle à sec peut tourner indéfiniment ou corrompre les résultats.

Worktrees pour les agents parallèles

Lorsque vous exécutez plusieurs agents Claude Code simultanément, ils opèrent tous par défaut sur les mêmes fichiers du dépôt. Si deux agents modifient le même fichier en même temps, l'un écrasera le travail de l'autre. Les Git worktrees résolvent ce problème : un worktree est un répertoire de travail supplémentaire lié au même dépôt, extrait sur sa propre branche, de sorte que chaque agent dispose de fichiers isolés sans aucun chevauchement.

Vous créez un worktree avec git worktree add. Chaque worktree possède sa propre branche et sa propre copie des fichiers de travail sur le disque. Les agents s'exécutent dans des répertoires séparés et ne touchent jamais aux fichiers des autres. Une fois leur travail terminé, vous fusionnez les branches normalement.

Claude Code prend en charge ce schéma directement. La commande /worktrees (ainsi que le flag --worktree lors du lancement d'un sous-agent) indique à un agent dans quel chemin de worktree il doit opérer. L'agent orchestrateur crée les worktrees, en attribue un à chaque sous-agent, puis attend que tous aient terminé avant de fusionner.

• Aucune collision de fichiers : chaque agent n'écrit que dans son propre répertoire.
• Aucun conflit de branches : chaque worktree est sur sa propre branche.
• Point de fusion propre : l'orchestrateur fusionne toutes les branches après que les agents ont signalé leur complétion.
• Nettoyage facile : git worktree remove supprime le répertoire et le désenregistre.

Dispatcher des agents en parallèle

Quand une tâche peut être découpée en morceaux indépendants, les exécuter l'un après l'autre fait perdre du temps. Le fan-out consiste à lancer plusieurs agents (ou sous-processus) au même moment, chacun traitant une portion distincte du travail, puis à rassembler tous les résultats une fois qu'ils ont terminé. Claude Code supporte ce schéma grâce à l'outil Agent, qui permet à un agent orchestrateur de créer des agents enfants.

La règle essentielle est l'indépendance : les tâches que l'on distribue en fan-out ne doivent pas dépendre du résultat des autres. Si la tâche B a besoin que la tâche A soit terminée en premier, ces deux tâches doivent rester séquentielles. Les bons candidats au fan-out incluent : l'audit de fichiers distincts, la traduction d'un même contenu dans plusieurs langues, l'exécution d'un même prompt sur des jeux de données différents, ou la récupération de plusieurs URLs en parallèle.

Un workflow fan-out typique comporte trois étapes :

1. Décomposer : l'orchestrateur divise l'objectif en N sous-tâches indépendantes.
2. Dispatcher : il appelle l'outil Agent N fois, un appel par sous-tâche, sans attendre entre les appels.
3. Collecter : une fois que tous les agents ont répondu, l'orchestrateur fusionne ou résume les résultats.

Dans Claude Code, il est aussi possible de faire un fan-out au niveau du shell en utilisant --print (mode non interactif) et des processus en arrière-plan, puis de réunir les sorties. Cela fonctionne bien pour les tâches simples où vous contrôlez directement l'environnement shell.

Maîtriser le coût d'un fan-out à grande échelle

Un fan-out se produit quand un orchestrateur (l'agent coordinateur) lance plusieurs sous-agents en parallèle pour traiter différentes parties d'un problème simultanément. Chaque sous-agent consomme des tokens, donc le coût total d'un fan-out correspond à la somme des tokens en entrée et en sortie de chaque agent. Sans anticipation, les coûts s'envolent rapidement.

Le premier levier est la sélection du modèle par tâche. Chaque sous-agent n'a pas besoin du modèle le plus puissant. Réservez claude-opus-4-8 aux tâches qui exigent un raisonnement approfondi, comme les décisions d'architecture ou les analyses ambiguës. Utilisez claude-sonnet-4-6 pour les travaux de complexité moyenne, tels que la génération de code, et claude-haiku-4-5 pour les tâches simples et volumineuses comme la classification, la mise en forme ou l'extraction. Ce seul ajustement peut réduire le coût d'une exécution de 80 % ou plus.

Le deuxième levier est le réduction du contexte. L'entrée de chaque agent est facturée en totalité. Ne transmettez que la portion de contexte dont cet agent a réellement besoin : un fichier pertinent, un court résumé ou un objet structuré plutôt que l'intégralité de l'historique de conversation. Le prompt caching (réutilisation d'un préfixe commun entre agents) réduit davantage les frais liés au contexte répété lorsque plusieurs agents partagent un grand prompt système ou un document de référence.

Contrôles budgétaires pratiques à appliquer avant de lancer une flotte d'agents :

• Définissez max_tokens par agent au minimum nécessaire pour ce type de tâche.
• Limitez le nombre d'agents en parallèle : davantage de concurrence augmente le coût sans toujours améliorer la qualité.
• Ajoutez une étape d'estimation à blanc : comptez les tokens des entrées prévues avant de lancer une exécution complète.
• Utilisez la terminaison anticipée : si un résultat intermédiaire satisfait déjà le critère de succès, annulez les agents restants.
• Journalisez l'usage des tokens par appel d'agent et fixez un plafond absolu dans la boucle de l'orchestrateur.

Schémas pour des données d'agent propres

Dans un pipeline multi-agent (une chaîne de modèles IA qui se transmettent des résultats), la sortie d'un agent devient l'entrée du suivant. Si cette sortie est du texte libre, l'agent récepteur doit deviner la structure, ce qui provoque des erreurs silencieuses. La solution est la sortie structurée : forcer le modèle à retourner les données dans un format strict et lisible par les machines, comme JSON.

Claude prend en charge la sortie structurée via l'utilisation d'outils. Vous définissez un JSON Schema (une description formelle des champs, des types et des propriétés requises attendus) et vous le passez comme définition d'outil. Claude remplit alors ce schéma au lieu d'écrire du texte. Le résultat est un objet JSON que votre code peut analyser et valider sans aucune manipulation de chaîne de caractères.

Principales raisons d'imposer des schémas dans les chaînes d'agents :

• Fiabilité : les agents en aval reçoivent des clés et des types prévisibles, pas du texte ambigu.
• Validation : vous pouvez rejeter ou relancer une réponse dès qu'un champ requis est absent, avant que de mauvaises données ne se propagent.
• Observabilité : les journaux structurés sont plus faciles à rechercher, à comparer et à surveiller en production.
• Composabilité : tout agent qui parle le même schéma peut être échangé sans réécrire le code de liaison du pipeline.

Dans Claude Code, l'API Claude (l'interface HTTP que votre agent appelle par programmation) vous permet de passer un tableau tools avec un outil dont l'input_schema définit exactement ce que vous voulez recevoir. Définir tool_choice à {"type":"tool","name":"votre_outil"} force Claude à appeler cet outil à chaque fois, garantissant une sortie structurée pour chaque requête.

Reprendre et mettre en cache un workflow

Un workflow multi-agents (un pipeline où plusieurs sous-agents IA traitent différentes tâches en séquence) peut être coûteux à relancer entièrement à chaque modification d'une étape. La solution est la reprise partielle : relancer uniquement les étapes dont les entrées ont changé, et réutiliser les sorties de tout le reste.

Claude Code prend en charge cela via deux mécanismes complémentaires. La mise en cache des prompts (une fonctionnalité de l'API Anthropic) stocke le calcul au niveau des tokens pour un prompt système long et stable, ou pour un bloc de contexte, afin que le modèle évite de le retraiter lors de l'appel suivant. Cela réduit à la fois la latence et le coût. Les accès au cache sont facturés à environ 10 % du tarif normal des tokens d'entrée. Le cache est indexé par le texte exact du préfixe : même un seul caractère modifié dans le bloc mis en cache l'invalide.

Au niveau du workflow, vous contrôlez la reprise via des points de contrôle (checkpoints) : les sorties de chaque étape d'agent sont sauvegardées sur disque ou dans un store. Quand vous relancez le pipeline, chaque étape vérifie si son checkpoint est toujours valide (entrées inchangées) avant d'appeler le modèle. Les schémas courants incluent :

• Vérification par hachage de contenu : calculer le hash des entrées de l'étape et le comparer au hash stocké avec le checkpoint. Une correspondance signifie que l'étape est ignorée.
• Vérification par horodatage : ignorer l'étape si le fichier checkpoint est plus récent que tous les fichiers sources qu'elle lit.
• Invalidation explicite : passer un indicateur --from step-name à votre orchestrateur pour forcer la réexécution à partir d'une étape nommée.
• Graphe de dépendances : modéliser quelles étapes dépendent de quelles sorties ; invalider uniquement les étapes en aval quand une sortie en amont change.

Dans Claude Code, vous pouvez écrire cette logique dans un orchestrateur shell ou Node qui appelle claude avec l'indicateur --print (non interactif, affiche la réponse et quitte) et écrit chaque sortie dans un fichier. Au lancement suivant, lisez d'abord le fichier et ignorez complètement l'appel claude si le checkpoint est frais.

Le critique de complétude

Dans un pipeline multi-agents (une chaîne d'agents IA dont chacun réalise une tâche précise), le dernier goulot d'étranglement est rarement du contenu erroné. C'est du contenu manquant. Un critique de complétude est un agent final dont l'unique rôle est de se demander : "Qu'est-ce qui devrait être ici et qui ne l'est pas ?" Il passe en revue la sortie de tous les agents précédents par rapport au cahier des charges initial et signale les lacunes avant que le résultat n'atteigne l'utilisateur.

Cet agent est délibérément ciblé. Il ne réécrit pas, n'améliore pas le ton et ne vérifie pas les faits. Il compare uniquement la portée du cahier des charges à la portée de la sortie et renvoie une liste structurée d'omissions. Ce rôle restreint le rend rapide, économique (un modèle Haiku suffit généralement), et facile à tester.

Exemples courants de ce qu'un critique de complétude détecte :

• Une section mentionnée dans le cahier des charges qui n'apparaît jamais dans la sortie
• Un exemple promis dans l'introduction mais jamais rédigé
• Une contrainte (nombre de mots, audience, langue) abandonnée sans signalement
• Un point d'action d'un compte rendu de réunion reformulé jusqu'à disparaître

Le critique renvoie ses conclusions dans le pipeline sous forme de diff structuré (une liste de différences lisible par une machine). Un agent de second passage, ou l'orchestrateur lui-même (l'agent qui coordonne tous les autres agents), décide ensuite quelles lacunes combler, lesquelles accepter et lesquelles remonter à l'humain.

Les sous-agents tournent désormais en arrière-plan

Depuis Claude Code v2.1.198 (sortie le 1er juillet 2026), les sous-agents (instances Claude auxiliaires à qui vous déléguez une sous-tâche, comme « lance la suite de tests et rends-moi compte ») tournent en arrière-plan par défaut. La conversation principale continue de fonctionner pendant que le sous-agent travaille, et vous recevez une notification quand il termine. Cette notification apparaît dans la vue claude agents, un panneau listant tous les sous-agents en cours ou terminés, pour vérifier le statut sans interrompre votre propre travail.

C'est un vrai changement par rapport à l'ancien modèle mental. Avant cette version, lancer un sous-agent bloquait le fil principal : vous demandiez à Claude de déléguer une tâche, et toute la session attendait que ce sous-agent renvoie un résultat avant que vous puissiez taper quoi que ce soit d'autre. Ce modèle mental est désormais obsolète. Depuis le 1er juillet 2026, la délégation fonctionne par défaut en lancer-et-continuer : vous pouvez confier une tâche à un sous-agent et immédiatement continuer à discuter, éditer des fichiers, ou lancer un second sous-agent, pendant que le premier tourne en parallèle.

La même version a supprimé l'assistant de création /agents, l'ancienne commande interactive qui vous guidait pas à pas dans la création d'un sous-agent. Depuis le 1er juillet 2026, il reste deux façons de créer un sous-agent : demander à Claude en langage naturel d'en créer un pour vous (par exemple, « crée un sous-agent qui relit les pull requests pour des problèmes de sécurité »), ou éditer directement les fichiers de définition sous .claude/agents/ dans votre projet. Il n'y a plus d'assistant guidé entre ces deux voies.

Les équipes d'agents (une fonctionnalité pour coordonner plusieurs sous-agents sur une tâche partagée) ont été revues plus tôt, le 15 juin 2026 dans la v2.1.178. Les outils TeamCreate et TeamDelete, qui permettaient auparavant de créer ou supprimer explicitement une équipe nommée, ont été supprimés. Désormais, chaque session dispose automatiquement d'une seule équipe implicite : il n'y a rien à créer ni à nommer. Ce modèle d'équipe a ajouté l'approbation de plan par coéquipier (une étape où le plan proposé par un coéquipier doit être approuvé avant son exécution) et les hooks de cycle de vie d'équipe (des scripts qui se déclenchent automatiquement à des moments comme le début ou la fin d'équipe, permettant de journaliser ou de conditionner ce qui se passe).

Les workflows dynamiques (le mécanisme de Claude Code pour décider automatiquement combien de sous-agents lancer et comment les enchaîner pour une tâche donnée) ont gagné deux contrôles utilisateur par la suite. D'abord, un réglage « Dynamic workflow size » est apparu dans /config à partir de la v2.1.202 le 6 juillet 2026, permettant de plafonner ou d'ajuster la taille que ces workflows automatiques sont autorisés à atteindre. Ensuite, la même série de versions a ajouté les attributs OpenTelemetry workflow.run_id et workflow.name. OpenTelemetry est un format standard pour exporter traces et métriques que des outils d'observabilité (comme Grafana ou Datadog) peuvent ingérer ; avec ces deux attributs attachés, une exécution d'orchestration (une exécution d'un workflow multi-sous-agents) devient traçable comme une unité nommée et identifiable au sein de la pile d'observabilité standard que votre équipe utilise déjà.

En pratique, cela change trois habitudes. D'abord, misez sur la délégation en lancer-et-continuer : pour les sous-tâches indépendantes (une passe de lint, une mise à jour de documentation, une recherche de fond), confiez-les à un sous-agent et continuez à travailler plutôt que d'attendre sans rien faire. Ensuite, attendez encore de manière synchrone quand l'étape suivante dépend vraiment du résultat du sous-agent, par exemple si vous ne pouvez pas rédiger le résumé avant que le sous-agent de recherche ne renvoie ses conclusions ; l'arrière-plan par défaut ne signifie pas que chaque étape doit tourner sans surveillance. Enfin, ajustez votre boucle de relecture : au lieu de regarder un indicateur de chargement bloquant, vous vérifiez désormais périodiquement la vue claude agents pour les notifications de fin, ce qui fait que relire le travail d'un sous-agent terminé devient une étape distincte et délibérée plutôt que quelque chose qui vous est imposé dès qu'une tâche se termine.

Le fan-out massif qui va vraiment jusqu'au bout

Un fan-out (faire démarrer de nombreux agents en même temps pour travailler sur des morceaux indépendants d'un travail) paraît simple jusqu'à ce qu'on essaie à grande échelle. Ce cours que vous êtes en train de lire a été construit par un fan-out de 166 agents, un agent par leçon, et faire en sorte que cela aboutisse vraiment (les 166 fichiers arrivant sur le disque, corrects et complets) a nécessité quatre règles durement acquises. Enfreignez l'une d'elles et l'exécution soit se bloque, soit perd du travail en silence, soit brûle de l'argent pour rien.

Règle 1 : ne jamais demander à un seul agent de produire un livrable volumineux entier en une seule réponse. C'est la règle anti-monolithe. Si vous dites à un agent "écris les 166 leçons et renvoie-les moi", il va se heurter à la limite de sortie par message (la quantité maximale de texte qu'un modèle peut générer dans une seule réponse) en plein milieu, la réponse est coupée, rien n'est écrit sur le disque, et la tâche entière paraît impossible alors que chaque leçon individuelle était facile. La solution consiste à fractionner par axe : un agent par langue, un agent par fichier, un agent par leçon. Chaque agent écrit son propre fichier sur le disque via son propre appel d'outil Write, et l'orchestrateur parent ne récupère qu'une minuscule ligne de statut ("terminé, p9l13.js, 3200 octets") au lieu du contenu complet. La fenêtre de contexte du parent n'a jamais besoin de contenir 166 leçons à la fois, seulement 166 reçus d'une ligne.

Règle 2 : connaître le plafond de concurrence avant de planifier l'exécution. Les orchestrateurs ne font pas tourner un nombre illimité d'agents en parallèle. En juillet 2026, les workflows Claude Code font tourner au maximum environ 16 agents simultanément, mettant le reste en file d'attente pour démarrer au fur et à mesure que des créneaux se libèrent, avec un plafond de 1000 agents à vie par workflow. Cela signifie qu'une tâche de 166 agents s'exécute en environ 10 à 11 vagues de 16, et non en une seule rafale instantanée. Au-delà d'environ 80 agents lancés en une seule rafale, la limitation côté serveur (l'infrastructure qui ralentit ou rejette les requêtes pour se protéger) apparaît même en utilisant des modèles moins coûteux comme Sonnet ou Haiku, pas seulement les plus chers. En pratique, il vaut mieux découper les grosses tâches en vagues délibérées (par exemple, des lots de 15 à 20) plutôt que de tout lancer d'un coup en espérant que le planificateur s'en sorte.

Règle 3 : vérifier la couverture par les artefacts, pas par les affirmations des agents. Les agents se trompent dans le décompte, surtout sous charge : l'un peut prétendre avoir réussi tout en écrivant au mauvais chemin, en sautant un fichier, ou en tronquant silencieusement. Ne jamais faire confiance au flot de messages "terminé !" comme preuve que la tâche est complète. Au lieu de cela, une fois la vague terminée, comparez l'ensemble des clés ou noms de fichiers de sortie attendus (la liste que vous avez planifiée avant le lancement) avec ce qui existe réellement sur le disque. Pour une exécution de 166 leçons, cela signifie lister les 166 noms de fichiers attendus et les comparer à un listing de répertoire. En pratique, cela révèle généralement 1 à 2 écarts, pas des dizaines, donc la solution consiste à les combler à la main ou avec un agent de reprise ciblé plutôt que de relancer la totalité des 166 agents.

Règle 4 : basculer vers la Batch API dès qu'une tâche est embarrassamment parallèle et dépasse environ 50 appels. "Embarrassamment parallèle" signifie que chaque unité de travail est entièrement indépendante des autres, sans état partagé, sans exigence d'ordre. La Batch API (le point de terminaison de traitement asynchrone en masse d'Anthropic) tourne sur son propre pool de limite de débit, complètement séparé de votre quota interactif normal, avec une remise de 50 pour cent par rapport au tarif standard. Le compromis, c'est que les résultats reviennent de manière asynchrone (vous soumettez le lot entier, puis vous interrogez ou attendez la fin) plutôt qu'en flux continu tour par tour. Pour une exécution ponctuelle de 166 leçons, le fan-out interactif était le bon choix car la vitesse d'itération comptait plus que le coût ; pour une tâche récurrente de 50 appels indépendants ou plus sans urgence, la Batch API est le meilleur choix par défaut.

Deux autres habitudes portent leurs fruits sur chaque exécution à grande échelle. D'abord, dirigez les étapes mécaniques (mise en forme, extraction, réécritures simples, génération de fichiers directe) vers des modèles moins coûteux comme Sonnet ou Haiku, et réservez le modèle le plus cher aux étapes qui exigent du jugement : évaluer la qualité, résoudre des conflits, synthétiser le résultat final. Ensuite, déclarez toujours explicitement tout plafond silencieux : si vous n'avez échantillonné que les 20 premiers résultats, ou traité les 50 premiers fichiers puis vous êtes arrêté, dites-le explicitement dans la sortie. Personne en aval ne devrait prendre une exécution partielle pour une exécution complète simplement parce que le résumé sonne avec assurance.

Ré-auditer les workflows persistés avant relance

Un script de workflow qui tournait parfaitement la semaine dernière peut discrètement vous coûter cinq fois plus cher aujourd'hui, sans qu'une seule ligne ait changé. Cette leçon couvre un mode de défaillance propre à l'orchestration persistée : scripts de workflow sauvegardés, pipelines réutilisables, tout fichier d'automatisation qui survit à la session qui l'a écrit.

Le mécanisme, c'est l'héritage. Dans un script de workflow, un appel agent() sans option model explicite hérite du modèle de la session qui l'exécute, pas du modèle de la session qui l'a écrit. Écrivez le script pendant une session sur un modèle intermédiaire, et les étapes mécaniques tournent implicitement au rabais. Relancez le même fichier la semaine suivante depuis une session sur le modèle haut de gamme, et chacune de ces étapes tourne désormais sur le cerveau le plus coûteux disponible : silencieusement, avec des résultats identiques sur le travail facile, pour un coût et une latence plusieurs fois supérieurs. Rien ne plante. Rien n'avertit. La facture est le seul symptôme.

L'auteur est tombé exactement dans ce piège en juillet 2026 : un pipeline persisté issu d'une session précédente, relancé sous une session sur le modèle phare, a envoyé toute une flotte d'agents d'extraction mécanique vers le modèle phare parce que les premières étapes du script ne portaient aucun routage explicite. Le correctif a pris deux minutes ; le repérer a pris plus longtemps. D'où la règle qui se généralise :

Tout script persisté se ré-audite avant relance, même s'il a déjà tourné. La checklist est courte :

• Chaque étape mécanique porte un model explicite (et un effort bas là où c'est supporté). Extraction, classification, mise en forme, traduction : le plus petit modèle qui passe.
• Les étapes de jugement et de vérification portent un modèle fort choisi explicitement, monté en capacité plutôt que multiplié en nombre.
• Rien ne repose sur l'héritage pour ce qui compte : modèle, effort, chemins de sortie, plafonds. Les valeurs par défaut héritées sont du contexte, et le contexte change entre les sessions.
• Les plafonds déclarés correspondent toujours à la réalité : une borne top-N ou une politique de skip-retry qui avait du sens au moment de l'écriture peut silencieusement tronquer les entrées plus volumineuses d'aujourd'hui.

Le principe plus profond dépasse le routage de modèle : une automatisation persistée est un instantané d'hypothèses. Le modèle de la session, le paysage des quotas, l'organisation des dossiers, les limites de débit de l'API, jusqu'aux fichiers qui existent : tout cela était vrai au moment où le script a été écrit, et rien de tout cela n'est garanti aujourd'hui. Épinglez en version ce qui ne doit pas dériver (options explicites), et re-vérifiez à la relance ce qui ne peut pas être épinglé (l'environnement). Traitez un workflow poussiéreux comme un script de déploiement poussiéreux : vous ne pointeriez pas le déploiement du mois dernier vers la production d'aujourd'hui sans l'avoir relu d'abord.

Une convention pratique qui rend l'audit quasi gratuit : gardez un commentaire d'en-tête dans chaque workflow persisté indiquant sa table de routage (quelles étapes tournent sur quel modèle et pourquoi) et la date de son dernier audit. La vérification à la relance ne prend alors que trente secondes de comparaison entre l'en-tête et le code, au lieu de dix minutes à redériver l'intention depuis la structure du pipeline.