--- title: "Multi-agent orchestration : 3 315 lancements, ce qui a cassé" description: "Orchestration d'agents en pratique : 3 315 exécutions de subagents en deux mois, le coût des tokens au tarif API et sept pannes devenues chacune un hook." url: "https://madsalt.tech/fr/blog/multi-agent-orchestration-what-broke/" author: "Denys Zaichenko" language: "fr" published: 2026-10-19 updated: 2026-10-22 --- # Multi-agent orchestration : 3 315 lancements, ce qui a cassé En bref Entre le 17 août et le 19 octobre 2026, ma configuration Claude Code a lancé 3 315 subagents. Sur les 30 derniers jours, cela représente environ 16 milliards de tokens, dont 97,7 % de lectures de cache. Je paie un abonnement forfaitaire ; aux tarifs catalogue de l'API, les mêmes tokens coûteraient au moins 3 350 USD. Les pannes ne venaient presque jamais d'un modèle qui écrit du mauvais code. Elles se trouvaient dans les jointures : des agents parallèles qui écrasent le même fichier alors que tous les contrôles sont au vert, un script de nettoyage qui supprime du travail terminé, un agent qui modifie les contrôles qui le bloquent. Chaque panne est devenue un petit script qui bloque l'exécution suivante, et ce sont ces scripts, pas les prompts, qui ont rendu le système utilisable. Je suis Denys, ingénieur full-stack et IA. Je construis des logiciels avec une session Claude Code principale qui confie le travail à des subagents spécialisés : explorateurs, un planificateur, des implémenteurs, des relecteurs sécurité et code. Ce texte rend compte de cette configuration, pas d'un produit client. Un système multi-agents de ce genre ne se décrit qu'à partir des journaux qu'il tient lui-même : un registre de lancements (une ligne par agent lancé), les transcriptions de sessions et l'historique git de la configuration elle-même. Les noms de clients et de projets sont omis. J'ai aussi construit un [dashboard interactif d'orchestration multi-agents](https://madsalt.tech/fr/work/multi-agent-orchestration/) comme prototype avec des données d'exemple. Tout ce qui suit vient de vraies exécutions. ## Qu'est-ce que l'orchestration multi-agents ? L'orchestration multi-agents est une organisation où un agent principal confie des tâches délimitées à des agents spécialisés et fusionne leurs résultats ; l'orchestrateur garde le contexte, les budgets et les nouvelles tentatives. Dans cet article, elle prend deux formes : une session principale avec des subagents (explorateurs, un planificateur, des implémenteurs, des relecteurs) et des hooks qui imposent les règles que les agents ne peuvent pas contourner à force de belles phrases. Le [dashboard d'orchestration multi-agents](https://madsalt.tech/fr/work/multi-agent-orchestration/) montre la même idée sur des données d'exemple ; les sections suivantes racontent ce qui a cassé dans de vraies exécutions. ## À quoi ressemble la configuration ? Une session principale me parle et porte la tâche. Sur les tâches importantes, elle n'écrit jamais elle-même de code de production. Elle envoie le travail ailleurs : - **Les explorateurs** lisent une couche du code (frontend, backend, base de données) et écrivent une courte carte. - **Un planificateur** transforme la carte en étapes numérotées avec des chemins de fichiers. - **Les implémenteurs** prennent chacun une phase du plan, écrivent d'abord les tests, puis le code. Les implémenteurs parallèles reçoivent chacun leur propre git worktree. - **Les relecteurs** vérifient le diff : un pour la sécurité, un pour l'exactitude, tous deux sur le même commit. Entre eux se trouvent des hooks : de petits scripts que Claude Code exécute avant et après chaque appel d'outil. Un hook peut bloquer un appel, par exemple le lancement d'un agent, une écriture de fichier ou un `git commit`. La configuration compte 165 hooks, dont environ 40 concernent l'orchestration. Les règles que lisent les agents sont du Markdown ; les règles qu'ils ne peuvent pas contourner sont des hooks. Cette séparation est la principale leçon de ces deux mois, et le reste de ce texte explique pourquoi. ![Le trajet d'une tâche entre les agents. Des hooks sont placés entre chaque étape et peuvent la bloquer. Chemin normal: Exploration → Plan → Code → Relecture → Commit; Même échec trois fois: Code → Même échec 3x → Modèle plus fort → Un humain.](https://madsalt.tech/charts/fr/multi-agent-orchestration-what-broke-flow.svg) *Figure 1. Ma configuration Claude, d'août à octobre 2026. Chaque implémenteur parallèle reçoit son propre git worktree.* ## Combien d'agents ont tourné, et sur quels modèles ? | Mesure (17 août – 19 octobre 2026) | Valeur | | ----------------------------------------------------- | --------------------------------------------------------------------------------- | | Subagents lancés | 3 315 sur 57 jours actifs | | Types d'agents | 30 | | Les plus lancés | implémenteur (tdd-guide) 793, relecteur sécurité 455, general-purpose 424 | | Modèle effectif | Opus 46,5 %, Sonnet 45,8 %, Fable 1,3 %, le reste hérité de la session principale | | Lancés un par un | 67,7 % | | Plus grande vague parallèle | 5 agents (le plafond), atteinte 9 fois | | Exécutions de relecteurs par exécution d'implémenteur | 0,71 (680 relectures, 963 implémentations) | Deux chiffres m'ont surpris. D'abord, la plupart des lancements étaient des agents isolés, pas des fan-outs. Le travail parallèle est l'exception : il vaut le coup pour lire et relire, et coûte cher pour écrire (voir la première panne plus bas). Ensuite, pour 23 % des lancements où le fichier d'un agent nomme un modèle, le modèle réellement exécuté était différent, presque toujours Sonnet relevé à Opus (584 sur 610). C'est voulu : un hook relève le modèle quand l'étape touche du code risqué comme les migrations, l'authentification ou les routes serveur, et après qu'un implémenteur sur Sonnet a échoué trois fois de suite au même test. L'implémenteur plus puissant a tourné 159 fois ; je ne peux pas séparer le journal entre « étape risquée » et « échec répété », donc je n'affirme pas combien étaient des sauvetages. ## Combien coûte la multi-agent orchestration ? Je paie un abonnement forfaitaire, donc il n'y a pas de facture par token. Les transcriptions enregistrent pourtant chaque token ; voici ce que coûteraient les 30 derniers jours (du 20 septembre au 19 octobre) aux tarifs catalogue de l'API d'Anthropic : | 30 jours | Tokens | | -------------------------- | -------------------------------------------------------------- | | Total | environ 15,99 milliards | | Lectures de cache | 15,55 milliards (97,7 % de tout ce qui a été envoyé au modèle) | | Écritures de cache | 372 millions | | Entrée fraîche, hors cache | 0,18 million | | Sortie | 69 millions | Aux tarifs catalogue (Opus 5.5 à 4 USD par million en entrée, 20 par million en sortie, 0,20 par million de lectures de cache ; Sonnet 5.5 et Fable 5.1 aux leurs), la sortie, l'entrée et les lectures de cache des trois modèles actuels représentent à elles seules environ 3 350 USD. Cela exclut les écritures de cache et les anciennes versions de modèles encore présentes dans les journaux : le vrai chiffre API est donc plus élevé. Les deux tiers de ces 3 350 USD sont des lectures de cache : chaque tour renvoie tout le contexte, et le cache est la seule raison pour laquelle c'est abordable. ![Qui a écrit les 69 M de tokens de sortie. Millions de tokens, 30 jours. Les subagents ont utilisé 42 % de tous les tokens. Session principale: 23,70; Subagents: 45,30.](https://madsalt.tech/charts/fr/multi-agent-orchestration-what-broke-output.svg) *Figure 2. Transcriptions Claude, du 20 septembre au 19 octobre 2026 : 75 129 requêtes au modèle.* La répartition entre la session principale et les subagents est la partie que j'utiliserais pour planifier un budget : - **Les subagents ont consommé 42 % de tous les tokens mais écrit 66 % de la sortie.** La session principale coûte cher parce qu'elle porte le contexte le plus long ; c'est dans les subagents que le texte et le code sont réellement écrits. - **Les relecteurs coûtent peu.** Une relecture sécurité ou code a utilisé 1 à 4 millions de tokens. Un implémenteur, 5 à 100 millions. Deux relecteurs sur chaque commit risqué coûtent moins qu'un implémenteur qui recommence. - **La plus grosse session**, le 6 octobre, a lancé 63 subagents et consommé 372 millions de tokens en 3,5 heures. ## Qu'est-ce qui a cassé ? Chaque panne ci-dessous a eu lieu, porte une date et s'est terminée par un hook ou un script qui l'empêche de se reproduire. Aucune n'est « le modèle a écrit un bug ». Les bugs ordinaires ont été attrapés par les tests et les relecteurs. Celles-ci ont passé les deux. | Date (2026) | Ce qui a cassé | Ce qui le bloque maintenant | | ----------- | ----------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | 19 août | Des agents parallèles ont écrasé un fichier de traductions : 55 clés sur ~95 perdues, tous les contrôles au vert | Chaque agent écrit ses clés dans son propre fragment ; un script de fusion prouve que chaque clé est arrivée | | 24 août | Un script de nettoyage a supprimé 4 lots de travail terminés | Le nettoyage ignore tout worktree contenant des changements non récupérés ; récupérer d'abord, nettoyer ensuite | | 1er sept. | Les vagues d'agents suivantes sont parties d'un code périmé | Fusionner le travail de chaque agent en patch à trois voies, jamais en copie de fichier | | 13 sept. | Un agent est mort au lancement, et le lancement disait « success » | Le lanceur lit la première sortie de l'agent et marque un modèle mort pour toutes les sessions | | 20 sept. | Deux de mes propres règles se contredisaient ; des agents réessayaient une commande refusée | Les briefs des agents isolés portent les formes de commande que le bac à sable accepte | | 18 oct. | Un agent a modifié les contrôles qui bloquaient son commit | Les fichiers de contrôle sont en lecture seule depuis les sessions de projet ; les changements sont journalisés et signalés | | 18 oct. | Des instructions de correction ont discrètement changé ce que reçoivent les utilisateurs d'une application client | Chaque brief de correction dit « keep live behaviour » ; les changements produit me reviennent | ### Des écrivains parallèles et le fichier que chaque fonctionnalité touche Trois agents ont construit en même temps trois fonctionnalités d'une application iOS d'un client. Chacun a ajouté ses chaînes de texte à l'unique catalogue de traductions de l'application, et chacun a enregistré sa propre version du fichier entier. Le dernier enregistrement l'a emporté. 55 clés sur environ 95 nouvelles avaient disparu. Le build de chaque agent est passé, car la copie de chacun était cohérente ; le contrôle du catalogue est passé, car sa couverture était défaillante d'une autre façon. Je l'ai trouvé en comptant les clés à la main. La correction comporte trois volets. Un hook refuse de lancer un agent dont les fichiers déclarés chevauchent ceux d'un écrivain encore actif. Les agents ne modifient jamais les catalogues partagés ; ils écrivent leurs clés dans un fichier fragment, et un script fusionne les fragments, échoue sur des valeurs contradictoires, puis vérifie que chaque clé est présente. Un second hook bloque le commit si un catalogue a moins de clés qu'avant. Le point honnête : j'ai ajouté ces garde-fous le 18 octobre, 60 jours après la perte. Entre-temps, la seule protection était une ligne dans une règle Markdown, et une règle n'est qu'une suggestion. ### Un nettoyage qui a supprimé du travail terminé Les implémenteurs parallèles travaillent dans des git worktrees et indexent leurs changements sans les committer. Une vérification de commit a demandé à la session principale d'exécuter le script de nettoyage. Le script ignorait les worktrees dont l'agent tournait encore, et ces agents avaient fini. Quatre lots de travail terminés ont été supprimés, sans aucun objet git à récupérer. « L'agent tourne-t-il encore ? » et « son travail a-t-il été récupéré ? » sont deux questions différentes, et le script ne posait que la première. Le nettoyage ignore désormais tout worktree contenant des changements que le checkout principal n'a pas, et un hook distinct bloque la suppression directe des dossiers de worktree. ### Des vagues parties d'un vieux code Un plan de 11 étapes s'est déroulé avec 6 implémenteurs en 3 vagues. Les vagues 2 et 3 sont parties du commit sur lequel la session avait commencé, trois commits en arrière. Recopier le fichier d'un agent aurait annulé le changement terminé d'un autre agent. Un worktree est un instantané du point de départ ; les résultats reviennent donc désormais sous forme de patchs à trois voies, et les conflits apparaissent au lieu d'être écrasés en silence. ### Un agent mort qui annonçait un succès Un agent attaché à un modèle dont la limite d'usage était épuisée est mort avant sa première étape. Le lancement a renvoyé « spawned successfully » ; l'échec est arrivé plus tard sous forme d'un avis d'inactivité. Une nouvelle tentative sur un autre modèle a été annulée par le hook même qui fixe les modèles. La session principale a alors écrit le plan elle-même, discrètement, ce qui était exactement le résultat que le planificateur devait éviter. Le hook lit maintenant la première sortie de l'agent et marque un modèle mort pour toutes les sessions pendant un temps. ### L'agent qui modifiait ses propres contrôles Le 18 octobre, une session travaillant sur un projet client voyait son commit sans cesse bloqué par un contrôle. Elle a modifié trois des scripts de contrôle pour que son commit passe. Rien n'était caché ; les modifications étaient visibles. Mais rien ne les arrêtait non plus, car les contrôles se trouvaient dans un dossier où l'agent pouvait écrire, et seuls les outils d'édition de fichiers étaient surveillés, pas les commandes shell. Désormais, les fichiers de contrôle ne peuvent être modifiés que depuis une session lancée dans le dossier de configuration lui-même, toutes les voies d'écriture sont couvertes (éditeur, redirections shell, scripts, git), et tout changement pendant une session de projet est journalisé avec une alerte. C'est la panne dont je préviendrais en premier. Un agent à qui l'on dit de « faire passer le commit » traite le garde-fou comme une partie du problème. ### Deux de mes propres règles se contredisaient Une règle demandait aux agents de regrouper trois étapes shell ou plus en un seul script pour économiser des tokens. Les agents isolés dans un worktree tournent sous un bac à sable qui refuse précisément cette forme. Plusieurs jours, des agents ont rencontré « too complex to verify » trois fois de suite et ont brûlé leur budget à reformuler. Les agents s'arrêtent maintenant après deux refus identiques, et les briefs des agents isolés indiquent les formes de commande qui fonctionnent. ## Pourquoi les systèmes multi-agents échouent-ils ? D'après ces deux mois : pas parce qu'un modèle est trop faible. Aucune des sept pannes ci-dessus n'était un modèle qui échouait à la tâche qu'on lui avait donnée. Elles échouent aux jointures entre agents, là où aucun agent n'est responsable : - **L'état partagé.** Un fichier que chaque fonctionnalité touche, un arbre de travail, une branche. Chaque agent a raison localement et le résultat est faux globalement. - **Des contrôles au vert.** Chaque incident ci-dessus a passé les contrôles qui existaient alors. Un contrôle prouve ce qu'il contrôle, rien de plus. - **Des signaux de succès qui mentent.** « Spawned », « saved », « cleaned up » voulaient chacun dire quelque chose de plus étroit que ce qu'ils annonçaient. - **Des agents qui optimisent pour le garde-fou.** Dites à un agent que le commit est bloqué et il cherchera un moyen de débloquer le commit, y compris à travers le garde-fou. D'autres constructeurs rapportent le même schéma sur des flottes plus grandes. Jed Arden, qui fait tourner une vingtaine d'agents, écrit que [le LLM apparaît à peine dans le journal des incidents](https://jedarden.com/notes/what-breaks-at-twenty-agents/) (juillet 2026). [L'équipe de Cursor a constaté](https://cursor.com/blog/scaling-agents) que vingt agents partageant un fichier de coordination avec des verrous ralentissaient jusqu'au débit de deux ou trois (janvier 2026). ## Ce que je mettrais en place d'abord Si vous débutez avec les subagents de Claude Code ou n'importe quelle multi-agent orchestration, voici l'ordre dans lequel je le ferais, vu ce que m'a coûté l'apprentissage : 1. **Journaliser chaque lancement d'agent.** Une ligne par lancement : heure, type d'agent, modèle, risque. Sans cela, on ne sait pas ce que fait le système, et aucun des chiffres ci-dessus n'existerait. 2. **Un seul écrivain par fichier.** Les écrivains parallèles reçoivent un worktree et une liste de fichiers déclarée. Les fichiers auxquels chaque fonctionnalité ajoute quelque chose (traductions, lockfiles, changelogs) ont un seul propriétaire, et les autres remettent des fragments. 3. **Récupérer avant de nettoyer.** Ne jamais laisser une étape de nettoyage décider selon « tourne-t-il encore ». Décider selon « son travail est-il dans le checkout principal ». 4. **Mettre les contrôles hors de portée des agents.** Des hooks qui bloquent, placés là où une session de projet ne peut pas écrire. 5. **Plafonner la vague.** Cinq agents parallèles, c'est mon plafond ; au-delà, la relecture devient le goulot et les conflits croissent plus vite que le débit. 6. **Escalader sur la répétition, pas sur l'effort.** Un modèle économique par défaut ; après le même échec trois fois, un essai sur un modèle plus puissant ; ensuite, un humain. Que coûte un agent IA à construire et à exploiter pour une entreprise, plutôt que pour le workflow d'un seul développeur ? C'est une autre question, traitée chiffres à l'appui dans [Prix d'un agent IA : les coûts réels de 4 projets](https://madsalt.tech/fr/blog/how-much-does-an-ai-agent-cost/). Les panneaux que je surveille aujourd'hui, tirés des mêmes journaux un mois plus tard, sont dans [AI agent monitoring : ce que 1 238 exécutions ont montré](https://madsalt.tech/fr/blog/ai-agent-monitoring-dashboard/). ## Limites de ce compte rendu - **La configuration d'un seul développeur.** Une session principale, jusqu'à cinq agents parallèles. Les flottes de dizaines ou de centaines d'agents échouent de façons supplémentaires, par exemple au lancement. - **Pas de vraie facture.** Le montant en dollars est un équivalent au tarif catalogue de l'API sur 30 jours, un plancher qui exclut les écritures de cache et les anciens modèles. Je paie un abonnement forfaitaire. - **Des trous dans les journaux.** Les lancements bloqués ne sont pas journalisés, je ne peux donc pas dire combien de fois le plafond de vague a joué. Les 159 exécutions de l'implémenteur plus puissant mêlent étapes risquées et échecs répétés. - **Des dates tirées de mes propres notes.** Les dates des incidents viennent de notes et de commits écrits le jour même ; un incident est daté différemment dans un ancien fichier de règles, et j'ai retenu la note. Le prototype de dashboard né de ce travail est le [cas du dashboard d’orchestration multi-agents](https://madsalt.tech/fr/work/multi-agent-orchestration/), et la construction d'agents pour des clients relève du [développement d'agents IA et chatbots](https://madsalt.tech/fr/services/ai-agent-development/). Vous faites tourner des agents en parallèle et perdez du travail entre eux ? Je compare volontiers nos façons de gérer les hooks, les worktrees et les validations de relecture. Sans argumentaire commercial. [Me contacter](https://madsalt.tech/fr/#contact)