En bref
Nous avons orchestré 35 agents LLM outillés en parallèle pour migrer 80 articles en 15 minutes, avec un taux de succès de 100%. La littérature académique teste au maximum 9 agents outillés dans des conditions contrôlées (Kim et al., 2025). Ce guide documente l’architecture concrète, positionne ce déploiement face à l’état de l’art, et analyse un comportement émergent inattendu de l’orchestrateur — ainsi que les mécanismes de contrôle qui transforment l’autonomie en fiabilité.
L’architecture en trois phases
Un déploiement à cette échelle se structure en trois phases distinctes.
Préparation (orchestrateur seul)
Avant tout dispatch : lecture de l’inventaire complet (80 articles avec source, destination, catégorie), lecture du mapping de liens croisés pré-calculé, nettoyage de 5 composants obsolètes, détection et correction de 2 conflits d’assignation (articles assignés à deux agents différents). Cette phase prend quelques minutes mais évite des collisions en phase parallèle.
Exécution parallèle (35 agents)
Les 35 agents ont été lancés en 3 batches de ~12 agents — pas en un seul bloc. Nos tests montrent qu’au-delà de 12-15 agents simultanés, le risque de throttling API augmente significativement.
La trace d’exécution du terminal montre les trois vagues successives : 12 agents (Acteurs + Fondamentaux), puis 11 agents (Infrastructure + Outils + début Techniques), puis 12 agents (suite Techniques + Enjeux). Chaque ligne affiche le nom de l’agent et son statut “Running in the background” — 35 lignes au total, toutes en exécution simultanée à l’issue du dispatch.
Chaque agent recevait : sa liste d’articles assignés (2 à 4), un lien vers un fichier d’instructions partagé sur disque (71 lignes), et les entrées de liens croisés pertinentes.
Consolidation (orchestrateur seul)
Après retour des 35 agents : comptage des articles produits (76 sur 80 — les 4 manquants étant des fusions planifiées), correction de 9 liens croisés cassés, suppression de 27 fichiers obsolètes, build du site (85 pages, 0 erreurs). Cette phase a pris ~7 minutes — près de la moitié de la durée totale. La consolidation ne scale pas aussi bien que l’exécution parallèle.
Trois conditions pour scaler au-delà de 20 agents
Nos tests sur une vingtaine de déploiements multi-agents (2 à 35 agents) montrent que trois conditions doivent être réunies simultanément.
Homogénéité des sous-tâches. Chaque agent fait la même opération : lire un article source, enrichir ses métadonnées, relire le contenu, écrire le résultat. Le prompt est quasi-identique d’un agent à l’autre — seuls les articles assignés changent.
Input complet fourni. Aucun agent n’a eu besoin de chercher de l’information. L’inventaire exhaustif, le mapping de liens croisés, les instructions détaillées — tout était fourni en amont. L’incertitude de chaque agent était nulle.
Découplage total en écriture. Chaque agent écrit dans un chemin de fichier différent. Aucun fichier partagé en écriture. Les conflits d’assignation ont été détectés et résolus avant le dispatch — un seul fichier partagé en écriture entre 35 agents créerait des race conditions impossibles à débugger.
Ce que dit la littérature
Deux mondes d’agents
La recherche multi-agents LLM se divise en deux catégories difficilement comparables.
D’un côté, les simulations à grande échelle déploient des milliers d’agents légers — un simple appel LLM par agent, sans outils ni raisonnement complexe. L’étude Generative Agents (Park et al., 2023) simule 25 agents dans un environnement social pour “des milliers de dollars”. AgentSociety (2025) monte à plus de 10 000 agents générant 5 millions d’interactions. MacNet (Qian et al., 2024, ICLR 2025) supporte plus de 1 000 agents en graphe acyclique dirigé, avec une performance qui suit une loi de croissance logistique.
De l’autre, les agents outillés — avec accès au filesystem, exécution de code, boucles de raisonnement multi-tours. L’étude la plus systématique (Kim et al., 2025, Google/UW) teste 180 configurations sur 1 à 9 agents, 5 architectures et 3 familles de LLM. Résultats clés :
| Métrique | Valeur |
|---|---|
| Amplification d’erreurs (agents indépendants) | 17,2× |
| Amplification d’erreurs (coordination centralisée) | 4,4× (containment) |
| Overhead tokens (indépendants → hybrides) | 1,6× à 6,2× |
| Gain coordination centralisée (tâches parallélisables) | +80,8% |
| Dégradation (raisonnement séquentiel) | -39% à -70% |
Le MAST dataset (Cemri et al., 2025) analyse 1 600 traces de défaillance sur 7 frameworks et identifie 14 modes d’échec. Les pannes de coordination représentent 36,9% des cas. Conclusion : “les gains de performance des systèmes multi-agents sur les benchmarks populaires sont souvent minimaux.”
Le gap documentaire
Aucune étude publiée ne documente de déploiement contrôlé entre 10 et 50 agents outillés. Kim et al. plafonnent à 9. Les simulations (MacNet, AgentSociety) utilisent des agents légers non comparables. ChatDev (Qian et al., 2023, ACL 2024) déploie 7 rôles spécialisés avec un taux de succès de 60% sur tâches non triviales — mais en workflow séquentiel, pas en parallèle.
Pourquoi le fire-and-consolidate contourne le plafond
Kim et al. identifient un seuil de saturation : au-delà de ~45% de performance en single-agent, la coordination multi-agents produit des rendements négatifs. Ce plafond vient de l’overhead de communication entre agents.
Le pattern fire-and-consolidate (orchestrateur dispatche → agents exécutent indépendamment → orchestrateur consolide) élimine cet overhead : les agents n’échangent jamais entre eux. L’overhead de coordination est nul par construction — mais uniquement parce que les tâches sont intrinsèquement indépendantes.
Ce qui relativise
Le taux de succès de 100% est lié aux conditions (tâches indépendantes, input complet, zéro couplage), pas à une supériorité intrinsèque. Dès que les tâches requièrent une coordination inter-agents, le plafond de Kim et al. s’applique pleinement. Il s’agit d’une seule exécution (N=1), non répliquée.
Quand l’orchestrateur improvise
Ce que montre la trace d’exécution
La capture d’écran du terminal montre un moment précis : l’orchestrateur annonce “Je crée un fichier d’instructions communes pour les agents, puis je dispatch les 35 agents.” Il écrit un fichier de 71 lignes sur le disque contenant le chemin cible, le format du frontmatter et les consignes de relecture. Puis il lance la première vague de 12 agents en arrière-plan.
Ce comportement n’était pas prescrit.
Ce que le prompt original prescrivait
Le prompt initial de l’opérateur faisait plus de 400 lignes, structuré en trois phases (préparation, parallèle, consolidation). Il contenait une section “Instructions communes à tous les agents” — un bloc de ~50 lignes que l’orchestrateur devait injecter dans le prompt de chaque sous-agent. Avec 35 agents, cela représentait ~1 750 lignes de contenu dupliqué.
L’orchestrateur a identifié cette inefficacité et l’a résolue de manière autonome : extraire les instructions dans un fichier partagé sur disque, puis transmettre à chaque agent un lien vers ce fichier au lieu du texte complet.
Avantages observés :
- Prompts allégés : chaque prompt agent ne contient que ses articles assignés
- Source unique de vérité : une correction dans le fichier s’applique à tous les agents des batches suivants
- Ajustabilité inter-batches : si le batch 1 révèle un problème, les instructions peuvent être corrigées avant le batch 2
La double lecture
Ce comportement relève d’une optimisation émergente : l’agent développe une stratégie d’efficience non prévue par l’opérateur. Le gain est réel — le déploiement est plus robuste et plus économe en tokens.
Mais c’est aussi une perte de visibilité partielle : l’opérateur ne sait pas, au moment du dispatch, que la structure du déploiement a changé. Si le fichier d’instructions contenait une erreur, les 35 agents la propageraient — alors que dans le design original, l’erreur aurait pu être détectée à la lecture du prompt.
Encadrer l’autonomie émergente
L’observation précédente pose une question structurelle : comment bénéficier de l’intelligence d’optimisation de l’agent sans perdre la visibilité sur ses décisions ?
Le challenge pré-exécution
Un mécanisme efficace consiste à imposer une phase de réflexion explicite avant toute action. L’agent doit identifier un obstacle pratique et une hypothèse implicite potentiellement fausse dans le plan qu’il s’apprête à exécuter. Ces deux éléments sont consignés en tête du livrable, visibles par l’opérateur.
Dans le cas du déploiement à 35 agents, ce challenge avait identifié le risque de conflits d’assignation — deux articles assignés au même agent dans le prompt original. Cela a permis de corriger 2 conflits avant le dispatch. Sans ce mécanisme, deux agents auraient écrit le même fichier, le second écrasant le premier silencieusement.
L’auto-évaluation architecturale
Un second mécanisme intervient après la phase de planification : l’agent évalue lui-même son architecture de déploiement. Le nombre d’agents est-il le bon ? Faut-il scinder certains groupes ? Y a-t-il des conflits de fichiers potentiels ?
Cette auto-évaluation ne remplace pas la validation humaine — elle la prépare. L’opérateur reçoit un diagnostic structuré au lieu d’un plan opaque, et peut intervenir sur des points précis plutôt que tout relire.
Du libre au cadré
| Sans mécanisme | Avec mécanisme |
|---|---|
| L’agent optimise silencieusement | L’agent explicite ses doutes puis optimise |
| L’opérateur découvre les changements après coup | L’opérateur valide avant exécution |
| Les erreurs se propagent à N agents | Les erreurs sont détectées avant dispatch |
Le principe : l’agent peut proposer des améliorations au plan, à condition de les signaler explicitement. L’optimisation émergente (fichier d’instructions partagé) reste souhaitable — mais elle doit être visible.
Métriques
| Métrique | Valeur |
|---|---|
| Agents déployés | 35 (tous même modèle) |
| Taux de succès | 100% (35/35) |
| Durée totale | 15 min 26 sec |
| Durée min / max d’un agent | ~110 sec / ~403 sec (ratio 3,7×) |
| Articles produits | 76 (80 - 4 fusions planifiées) |
| Liens croisés corrigés en consolidation | 9 |
| Tokens estimés | ~1,5 million (~43K par agent) |
| Build final | 85 pages, 0 erreurs |
L’écart de durée (ratio 3,7×) vient de la charge inégale : l’agent le plus lent traitait 4 articles avec fusions complexes, le plus rapide n’en traitait que 2 simples.
Ce qu’il faut retenir
- 35 agents outillés en parallèle se situent dans un gap documentaire : la littérature teste au maximum 9 agents outillés (Kim et al., 2025) ou 1 000+ agents légers (MacNet) — les deux ne sont pas comparables
- Le pattern fire-and-consolidate contourne le plafond de coordination en éliminant la communication inter-agents — mais uniquement pour des tâches intrinsèquement indépendantes
- À grande échelle, l’orchestrateur développe des stratégies d’optimisation non prescrites (fichier d’instructions partagé) — un gain d’efficacité qui implique une perte de visibilité pour l’opérateur
- Des mécanismes de contrôle (challenge pré-exécution, auto-évaluation architecturale) transforment l’autonomie émergente en autonomie encadrée — l’agent peut optimiser, à condition de signaler ses choix
- Trois conditions de scaling : homogénéité des tâches, input complet, zéro couplage en écriture. Si l’une manque, le taux de succès se dégrade
Sources
- Kim et al., “Towards a Science of Scaling Agent Systems”, arXiv 2025
- Cemri et al., “Why Do Multi-Agent LLM Systems Fail?” (MAST), arXiv 2025
- Qian et al., “ChatDev: Communicative Agents for Software Development”, ACL 2024
- Qian et al., “Scaling Large Language Model-based Multi-Agent Collaboration” (MacNet), ICLR 2025
- Park et al., “Generative Agents: Interactive Simulacra of Human Behavior”, ACM UIST 2023
- Anthropic, “Claude Code — Agent Tool documentation”, 2025
- D’après nos observations sur 23 déploiements multi-agents (2 à 35 agents), documentés entre janvier et mars 2026
Niveau de preuve : empirique — 1 exécution documentée, positionnée vs littérature académique (6 sources primaires).