Des centaines d’agents ne font pas une organisation

Le calcul se parallélise facilement. La cohérence, beaucoup moins. Les expériences de Cursor, Anthropic et OpenAI redécouvrent ce que la théorie des organisations savait déjà, et butent sur une difficulté qu’elle n’avait jamais rencontrée : des agents issus du même modèle peuvent partager les mêmes erreurs.

Vingt agents, le débit de deux ou trois

En janvier 2026, Cursor raconte une expérience qui ressemble moins à une démonstration d’intelligence artificielle qu’à un incident classique de systèmes distribués.

L’équipe fait travailler des agents de même niveau sur un même projet. Chacun consulte un fichier partagé, choisit une tâche, met son état à jour et utilise un verrou pour éviter que deux agents ne prennent le même travail. Sur le papier, le dispositif est simple. En pratique, les agents gardent leurs verrous trop longtemps, oublient de les libérer, essaient parfois de reprendre un verrou qu’ils possèdent déjà. Le mécanisme censé coordonner le travail devient lui-même le travail.

Le résultat est brutal. Avec vingt agents, Cursor observe un débit effectif équivalent à deux ou trois agents. L’essentiel du temps est passé à attendre.¹

Le problème n’était pas l’intelligence des agents. C’était leur organisation.

La scène est récente, mais l’idée ne l’est pas. En 1975, Frederick Brooks rappelait déjà qu’ajouter des personnes à un projet logiciel en retard peut le retarder davantage. La raison tient moins à la compétence individuelle qu’au coût des dépendances, de la communication et de l’intégration.² Les agents n’échappent pas à cette contrainte. Ils permettent simplement de la reproduire à une vitesse et à une échelle inédites.

Ce que paralléliser veut vraiment dire

Toutes les tâches ne se divisent pas de la même manière.

Il existe d’abord du travail dont les branches peuvent progresser presque indépendamment. Rechercher vingt entreprises, parcourir mille documents, tester plusieurs hypothèses distinctes ou exécuter des batteries de cas sont de bons candidats. Chaque branche peut produire un résultat sans attendre en permanence les autres.

À l’inverse, certains travaux sont couplés. Une décision d’architecture modifie les contraintes de toutes les autres. Deux personnes qui réécrivent la même section d’un document se gênent. Plusieurs agents qui modifient les mêmes fichiers doivent réconcilier leurs changements. Dans ce cas, ajouter des exécutants ne supprime pas les dépendances.

La loi d’Amdahl formulait dès 1967 ce plafond pour le calcul parallèle : la fraction qui doit rester sérielle finit par limiter l’accélération globale.³ Le même raisonnement s’applique au travail. Cent personnes peuvent inventorier cent bibliothèques en parallèle. Elles ne peuvent pas réécrire simultanément la même page sans décider qui tranche la version finale.

Cela ne signifie pas que le multi-agent fonctionne mal. Anthropic obtient au contraire un gain de 90,2 % sur son évaluation interne de recherche avec un orchestrateur Opus 4 et des sous-agents Sonnet 4, comparés à Opus 4 seul.⁴ Le cas d’usage est important : il s’agit de questions larges qui se décomposent naturellement en branches indépendantes, comme retrouver les membres des conseils d’administration d’un grand ensemble de sociétés.

Le prix est tout aussi instructif. Anthropic rapporte environ quatre fois plus de tokens pour un agent que pour une conversation classique, et environ quinze fois plus pour le système multi-agent. L’usage de tokens explique à lui seul 80 % de la variance de performance observée sur BrowseComp. L’entreprise précise surtout que les tâches de code offrent généralement moins de parallélisme véritable que la recherche, et que les domaines exigeant beaucoup de contexte partagé ou comportant de nombreuses dépendances se prêtent moins bien à ce type d’architecture.⁴

La documentation Claude Code formule la même recommandation de manière pratique : pour des tâches séquentielles, des modifications concurrentes d’un même fichier ou un travail fortement dépendant, une session unique ou des sous-agents sont souvent plus efficaces.⁵

Le multi-agent fonctionne, parfois remarquablement bien. La vraie question est ce qu’on lui donne à faire.

Le produit rare devient la décomposition

Un orchestrateur utile n’est donc pas seulement un répartiteur de tâches. Son travail essentiel consiste à fabriquer un découpage qui rende les branches suffisamment indépendantes pour que leur exécution simultanée produise réellement du débit.

L’expérience du compilateur d’Anthropic le montre de façon presque pédagogique. En février 2026, Nicholas Carlini décrit seize agents chargés d’écrire en Rust un compilateur C capable de construire le noyau Linux. Après près de 2 000 sessions Claude Code et environ 20 000 dollars d’API, l’équipe d’agents produit environ 100 000 lignes de code et compile Linux 6.9 sur x86, ARM et RISC-V.⁶

La coordination elle-même reste rudimentaire. Un agent revendique une tâche en créant un fichier texte dans un répertoire synchronisé par git. Les conflits de fusion sont fréquents, mais les agents savent généralement les résoudre. Le point décisif apparaît ailleurs.

Quand la compilation du noyau se présentait comme un seul gros échec, chaque agent rencontrait le même bug, le corrigeait puis risquait d’écraser le travail des autres. Seize agents voyaient seize fois le même problème. Le parallélisme n’apportait presque rien.

Anthropic a alors changé la structure du problème. Un harnais compilait l’essentiel du noyau avec GCC, utilisé comme référence, puis distribuait aux agents des fichiers distincts sur lesquels tester le nouveau compilateur. Le but final n’avait pas changé. Le travail, lui, était devenu discriminant et divisible.⁶

On ne parallélise pas un objectif. On parallélise une structure de travail.

Conway observait en 1968 que les systèmes conçus par une organisation tendent à refléter ses structures de communication.⁷ Avec les agents, la lecture peut être retournée : la structure du travail devrait déterminer la structure de l’équipe. Anthropic recommande ainsi de répartir les modifications pour que chaque coéquipier possède un ensemble de fichiers distinct plutôt que de faire travailler plusieurs agents sur les mêmes surfaces.⁵

Nos propres travaux nous conduisent à un critère encore plus opérationnel. Nous parallélisons ce qui peut être exécuté dans un ordre différent sans modifier le résultat final, par exemple récupérer des pages, extraire des affirmations ou rattacher des preuves. Nous sérialisons ce qui dépend de l’ordre, notamment la révision d’un état partagé et la décision. Dans un de nos systèmes de veille, une boucle sérielle coûtait de l’ordre de douze minutes par composant surveillé, surtout parce qu’elle relisait les mêmes pages. Le gain est venu d’un cache partagé et d’un découpage par page, pas d’un modèle plus rapide.

La hiérarchie revient par la fenêtre

Cursor finit par abandonner sa coordination horizontale. À la place, l’équipe sépare les responsabilités.

Des planners explorent le projet et créent les tâches. Des workers exécutent ces tâches sans devoir coordonner en permanence le reste de l’équipe. À la fin d’un cycle, un judge décide s’il faut en lancer un nouveau. Cette structure permet à Cursor de faire travailler des centaines de workers concurrents sur un même codebase. Dans l’expérience de navigateur, ils tournent près d’une semaine et écrivent plus d’un million de lignes réparties sur environ mille fichiers.¹

Ce volume n’est pas une mesure de qualité. Cursor le dit lui-même à propos d’une autre expérience de migration de Solid vers React : l’ensemble passait les premiers contrôles et la CI, mais demandait encore une revue attentive.¹ Ce qui compte ici n’est pas le nombre de lignes. C’est le changement de forme organisationnelle. Une hiérarchie minimale a remplacé une auto-organisation plate qui passait trop de temps à se coordonner.

L’étude MAST, publiée à NeurIPS 2025, donne un vocabulaire plus systématique à ces échecs. Les auteurs ont constitué un corpus de plus de 1 600 traces issues de sept frameworks multi-agents et identifié quatorze modes d’échec répartis entre conception du système, désalignement entre agents, puis vérification et terminaison.⁸ Les défaillances les plus fréquentes sont peu spectaculaires : étapes répétées, écart entre raisonnement et action, mauvaise compréhension des conditions d’arrêt, non-respect de la spécification. Ce ne sont pas d’abord des échecs d’intelligence. Ce sont des échecs de système.

Une prépublication de 2026, OrgAgent, pousse l’idée plus loin en organisant les agents comme une entreprise, avec trois couches de gouvernance, d’exécution et de conformité. Sur SQuAD 2.0 avec GPT-OSS-120B, cette structure hiérarchique améliore le score de 102,73 % par rapport à une configuration plate tout en réduisant la consommation de tokens de 74,52 %.⁹ Il s’agit d’un benchmark et d’un modèle, pas d’une loi générale. Le résultat reste intéressant parce que les auteurs identifient précisément les conditions favorables : affectation stable des compétences, flux d’information contrôlé et vérification en couches.

L’écho avec la théorie des organisations est difficile à manquer. Herbert Simon décrivait l’organisation comme une réponse à la rationalité limitée : diviser le travail, réduire l’information à traiter localement, agréger ce qui doit remonter, formaliser certaines décisions.¹⁰ Weber, de son côté, analysait la bureaucratie par ses avantages techniques de précision, de continuité, de connaissance des dossiers et de réduction des frictions.¹¹

Pour des agents, cette logique peut être traduite en une grammaire simple de contrôle partagé :

Opérateur	Fonction organisationnelle
Rôle	Restreindre l’espace d’action et clarifier le mandat
Procédure	Rendre des exécutions comparables
Preuve attendue	Conditionner l’acceptation à un élément vérifiable
Approbation	Introduire un contrôle avant effet
Séparation des rôles	Empêcher qu’un producteur valide seul sa propre production
Audit	Permettre de rejouer et d’expliquer ce qui s’est passé
Escalade	Router l’incertitude vers une autorité capable de trancher

Une organisation ne suppose pas des membres infaillibles. Elle construit des règles qui rendent leurs erreurs visibles, localisables et corrigibles.

Trop peu de structure produit du conflit. Trop de structure produit de la bureaucratie

Le mouvement inverse est tout aussi important.

Cursor avait ajouté un rôle d’intégrateur chargé du contrôle qualité et de la résolution des conflits. L’équipe l’a finalement supprimé. Selon son retour d’expérience, ce rôle créait davantage de goulots qu’il n’en résolvait, alors que les workers géraient déjà une partie des conflits eux-mêmes.¹

La conclusion de Cursor est précise : trop peu de structure entraîne conflits, duplication et dérive. Trop de structure introduit de la fragilité.¹

La théorie des organisations connaît aussi cette pathologie. Robert Merton décrivait dès 1940 le déplacement des buts, lorsque le respect de la procédure finit par prendre la place de l’objectif qu’elle devait servir.¹² Adler et Borys distingueront plus tard une formalisation coercitive, qui enferme l’exécutant dans le processus, d’une formalisation habilitante, qui lui donne au contraire les moyens de mieux agir.¹³

Les harnais d’agents ont le même choix. Une procédure peut prescrire chaque étape et multiplier les échanges obligatoires. Elle peut aussi se limiter à des points de contrôle.

C’est la direction que nous retenons dans nos travaux. Entre deux jalons, l’agent conserve sa liberté d’exécution. Au jalon, il doit produire la preuve attendue et cette preuve doit être contrôlée par un vérificateur distinct. On ne lui impose pas comment raisonner. On impose ce qui doit être démontré avant de poursuivre et à qui il faut rendre des comptes.

Cette distinction n’est pas purement esthétique. Des travaux présentés à EMNLP 2024 montrent que des contraintes de format plus strictes peuvent dégrader les capacités de raisonnement des modèles.¹⁴ À l’inverse, les travaux sur la supervision par étapes montrent l’intérêt de contrôler les étapes intermédiaires plutôt que d’attendre uniquement le résultat final.¹⁵

Une fonction de coordination ne mérite donc d’exister que si elle supprime plus de collisions qu’elle ne crée d’attente.

La règle vaut pour un verrou, un planificateur, une file d’admission, un arbitre, une mémoire partagée, une revue humaine ou un test. Chacun doit justifier son coût.

Le piège propre aux agents : des clones ne font pas un comité

Jusqu’ici, les organisations humaines ont déjà rencontré presque tous les problèmes décrits. Il reste pourtant une difficulté particulière aux systèmes d’agents : leurs membres peuvent être des variantes très proches du même modèle et partager leurs erreurs.

Le théorème du jury de Condorcet part d’une intuition séduisante. Si plusieurs votants sont indépendants et chacun légèrement meilleur que le hasard, la majorité devient plus fiable quand le groupe grandit.¹⁶ Les deux conditions comptent : compétence et indépendance.

Or l’indépendance ne va pas de soi chez les modèles.

En 2026, Guneet Kohli, chez Apple, évalue un panel de neuf modèles frontière appartenant à sept familles différentes. Sur les tâches étudiées, les neuf juges n’apportent qu’environ deux voix indépendantes effectives. Les erreurs sont corrélées, au point que le meilleur juge unique égale ou dépasse le panel complet dans les conditions testées. L’auteur conclut qu’augmenter la taille du panel ne remplace pas une évaluation réellement indépendante.¹⁷

Le résultat mérite d’être lu avec précision. Il porte déjà sur sept familles différentes. Il ne mesure pas directement neuf instances du même modèle. Il serait donc imprudent de transformer cette étude en chiffre universel sur les « clones ». Elle établit en revanche un fait plus général : compter les votants n’est pas compter l’information indépendante.

Une prépublication de Fudan publiée en mai 2026 observe un autre effet. Dans un système homogène piloté par le même LLM, augmenter le nombre d’agents peut d’abord améliorer la performance puis la dégrader. Sur un benchmark d’algèbre abstraite avec Llama-3.1-70B, les auteurs rapportent par exemple 72,55 % avec quatre agents contre 64,71 % avec huit, tandis que le coût en tokens croît fortement avec la taille du système.¹⁸ Il s’agit d’une prépublication et d’une architecture particulière. Le résultat est néanmoins cohérent avec une idée simple : la pluralité ne crée pas automatiquement de l’intelligence collective.

Chen et ses coauteurs avaient déjà observé en 2024 un phénomène comparable sur des systèmes de vote composés de plusieurs appels à un modèle. Ajouter des appels peut d’abord aider puis nuire, parce que les votes supplémentaires améliorent les questions faciles mais peuvent renforcer la mauvaise réponse sur les questions difficiles.¹⁹

Cognition formule l’objection de manière plus radicale : les actions contiennent des décisions implicites. Si des sous-agents prennent des décisions incompatibles sans partager leurs traces complètes, un intégrateur final peut se retrouver avec des morceaux impossibles à réconcilier.²⁰

La réponse n’est pas de supprimer tout parallélisme. Elle consiste à réserver le parallélisme aux parties du travail qui peuvent être réellement séparées, puis à fabriquer de l’indépendance là où l’on cherche de la vérification.

Un producteur et son vérificateur ne devraient pas être la même instance dans le même rôle. Mieux encore, tous les vérificateurs ne devraient pas être du même type. Une exécution de code, une requête directe sur une source, une règle métier ou une corroboration documentaire apportent des erreurs différentes de celles d’un second juge génératif. Le désaccord entre vérificateurs devient alors une information utile à escalader, plutôt qu’un bruit à moyenner.

Compter les sources ou les agents qui concordent n’est pas encore mesurer leur indépendance. C’est un chantier de recherche que nous menons, et probablement l’une des métriques qui manquent aujourd’hui aux systèmes multi-agents.

Il n’existe pas un bon modèle d’organisation, mais plusieurs régimes

Il serait tentant de conclure que la solution est simplement davantage de hiérarchie. Ce serait remplacer une erreur par une autre.

Les structures très contrôlées fonctionnent bien lorsque l’enjeu principal est la précision d’exécution : appliquer une procédure, vérifier une conformité, consolider un livrable, exécuter des tâches dont les rôles sont connus. Elles deviennent moins adaptées quand la valeur vient de l’exploration : concevoir une architecture, élaborer une stratégie, chercher la cause d’un bug encore inconnu.

La théorie des organisations décrit cette tension depuis longtemps. Burns et Stalker opposaient structures mécanistes et organiques. Mintzberg distinguait notamment la bureaucratie de l’adhocratie. March formalisait la tension entre exploitation de ce que l’on sait déjà faire et exploration de nouvelles possibilités.²¹

Le développement de produits chez Toyota apporte une autre intuition. Le set-based concurrent engineering consiste à faire vivre plusieurs solutions assez longtemps pour pouvoir les comparer, plutôt qu’à choisir immédiatement une option puis à la défendre coûte que coûte.²² Reinertsen formalise de son côté l’intérêt de limiter l’encours et de tirer le travail selon la capacité disponible plutôt que de pousser indéfiniment des tâches dans le système.²³

Les systèmes d’agents commencent à retrouver ces formes sans forcément les nommer.

Le Co-Scientist de Google, publié dans Nature en mai 2026, fait vivre plusieurs hypothèses qui sont générées, critiquées, classées par tournoi puis améliorées. La coordination n’est pas un plan central qui dicte toutes les étapes. Elle organise une compétition structurée entre alternatives avant validation expérimentale.²⁴

La documentation Claude Code conseille une logique proche pour le débogage : plusieurs coéquipiers peuvent tester des hypothèses concurrentes et chercher à réfuter celles des autres, afin d’éviter l’ancrage d’une investigation séquentielle.⁵

Nos travaux traitent donc ces formes comme deux régimes d’un même socle. Dans un régime de contrôle, les rôles et les points de validation dominent. Dans un régime d’exploration, les agents tirent le travail disponible, plusieurs hypothèses peuvent coexister et les moins prometteuses sont éliminées progressivement. Le journal, la vérification et la revue humaine restent présents dans les deux cas.

La forme de coordination doit suivre la nature de la tâche, pas le nombre d’agents disponibles.

Et un même processus peut changer de régime. L’exploration peut être large avant une décision, puis l’exécution devenir stricte une fois la décision prise. L’intégration, elle, gagne souvent à rester séparée du flux de production. On ne redessine pas la carte pendant qu’on marche dessus.

La production machine dépasse déjà la capacité humaine d’absorption

Cette question ne concerne plus seulement les laboratoires d’agents.

Le 6 septembre 2026, OpenAI publie un aperçu de l’usage de ses agents dans sa propre organisation de recherche. À la mi-août, l’entreprise mesure 3,1 journées-agent d’exécution pour chaque journée de travail humain. Le chercheur médian par usage d’agents consomme plus de 600 dollars d’inférence par jour aux prix API, et le 90e percentile dépasse 7 000 dollars.²⁵

Ces chiffres ne disent pas que trois journées-agent valent trois journées humaines. OpenAI insiste elle-même sur la difficulté d’interpréter les volumes d’exécution. L’entreprise note aussi que les agents nécessitent encore un pilotage humain important, en particulier lorsque les tâches se complexifient.²⁵

La tendance est néanmoins claire. En juin 2026, OpenAI indiquait déjà que ses utilisateurs internes du 99e percentile généraient régulièrement plus de soixante heures de tours d’agent Codex par jour, réparties sur plusieurs agents parallèles.²⁶

À mesure que le coût d’exécution chute, la contrainte se déplace vers tout ce qui se parallélise moins bien : définition du problème, intégration, vérification, arbitrage et acceptation.

C’est la même dynamique que nous décrivions en août à propos de la vérification. On peut augmenter le nombre de sorties beaucoup plus vite que la quantité de jugement disponible pour les absorber.²⁷ Un système qui escalade trop de cas ne résout d’ailleurs pas le problème. Il le transfère au décideur, qui finit par être saturé et peut valider par réflexe.

La bonne unité d’escalade n’est donc pas une alerte « risque élevé ». C’est un dossier instruit : ce qui est affirmé, les preuves qui l’étayent, les contradictions actives, la raison de l’escalade et les options possibles. L’humain n’a pas à refaire tout le travail de l’agent. Il doit pouvoir arbitrer le cas qui lui est présenté.

Le KPI pertinent n’est pas « combien d’agents ? »

Le nombre d’agents est une métrique de capacité installée. Il dit peu de chose sur le débit utile.

Une équipe agentique devrait plutôt suivre quelques mesures simples :

1. Taux de travail indépendant. Quelle part des tâches avance sans attendre une autre tâche ?
2. Ratio d’attente. Combien de temps est perdu à attendre un verrou, un merge, une décision ou une ressource ? Dans l’expérience initiale de Cursor, le débit de deux ou trois agents pour vingt lancés suggère que l’attente absorbait l’essentiel de la capacité.¹
3. Taux de collision. Quelle part du travail doit être annulée, refaite ou réconciliée ?
4. Nombre effectif de voix indépendantes. Combien d’informations réellement distinctes le système obtient-il lorsqu’il multiplie les juges ? Le panel étudié par Apple rappelle que neuf votes nominaux peuvent en contenir beaucoup moins.¹⁷
5. Temps d’intégration par unité produite. Combien coûte l’absorption d’un résultat supplémentaire ?
6. Temps humain de revue rapporté au temps humain économisé. L’automatisation a-t-elle supprimé du travail ou seulement déplacé celui-ci ?

Ces mesures font apparaître un plafond d’organisation. Au-delà d’un certain nombre d’agents, ajouter de la production n’accélère plus la livraison, parce que l’intégration, la décision ou la revue devient limitante.

La recommandation actuelle de Claude Code est révélatrice : commencer avec trois à cinq coéquipiers pour la plupart des workflows, puis augmenter seulement lorsque le travail bénéficie réellement d’une exécution simultanée. Sa documentation résume même qu’il vaut souvent mieux trois coéquipiers concentrés que cinq dispersés.⁵

Le bon nombre d’agents n’est donc pas une cible. C’est une conséquence du découpage.

Le multi-agent est un problème d’organisation du travail

Les progrès des modèles vont rendre de moins en moins coûteuse la création d’une force de travail logicielle massive. Il sera facile de lancer dix agents, puis cent, puis davantage.

Ce qui restera rare est la capacité à leur donner un travail admissible, à rendre les branches indépendantes quand elles peuvent l’être, à sérialiser les décisions quand elles doivent l’être, à fabriquer une vérification réellement indépendante, puis à accepter ou rejeter proprement ce qui est produit.

Une organisation n’est pas un nombre d’exécutants. C’est la grammaire qui les relie.

C’est précisément pour cette raison que, chez Cercle, nous ne pensons pas le Core Beyond comme un orchestrateur supplémentaire. Nous le concevons comme une couche d’organisation : rôles et droits, preuves attendues selon le type d’affirmation, séparation entre production et vérification, journal rejouable, puis escalade vers un dossier de revue humain lorsque le système ne doit plus décider seul.²⁸

Les Compagnons peuvent être nombreux. L’organisation, elle, tient dans ces règles.

La question n’est plus « combien d’agents pouvons-nous lancer ? ». Elle devient : combien de changements notre organisation peut-elle absorber sans perdre sa cohérence ?

Sources

1. Wilson Lin, Cursor, Scaling long-running autonomous coding, 14 janvier 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Frederick P. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1975. ↩

3. Gene M. Amdahl, Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities, AFIPS, 1967, https://doi.org/10.1145/1465482.1465560. ↩

4. Anthropic Engineering, How we built our multi-agent research system, 13 juin 2025. ↩ ↩²

5. Anthropic, Orchestrate teams of Claude Code sessions, documentation consultée le 15 septembre 2026. ↩ ↩² ↩³ ↩⁴

6. Nicholas Carlini, Anthropic Engineering, Building a C compiler with a team of parallel Claudes, 5 février 2026. ↩ ↩²

7. Melvin E. Conway, How Do Committees Invent?, Datamation, avril 1968. ↩

8. Mert Cemri, Melissa Z. Pan, Shuyi Yang et al., Why Do Multi-Agent LLM Systems Fail?, NeurIPS 2025. ↩

9. Yiru Wang, Xinyue Shen, Yaohui Han et al., OrgAgent: Organize Your Multi-Agent System like a Company, prépublication arXiv, 1er avril 2026. ↩

10. Herbert A. Simon, Administrative Behavior, 1947 ; The Sciences of the Artificial, 1969. ↩

11. Max Weber, Wirtschaft und Gesellschaft, 1922 ; traduction anglaise de référence dans H. H. Gerth et C. Wright Mills, From Max Weber, 1946. ↩

12. Robert K. Merton, Bureaucratic Structure and Personality, Social Forces, 18(4), 1940. ↩

13. Paul S. Adler et Bryan Borys, Two Types of Bureaucracy: Enabling and Coercive, Administrative Science Quarterly, 41(1), 1996. ↩

14. Zhi Rui Tam et al., Let Me Speak Freely? A Study On The Impact Of Format Restrictions On Large Language Model Performance, EMNLP Industry Track, 2024. ↩

15. Hunter Lightman et al., Let’s Verify Step by Step, ICLR 2024. ↩

16. Nicolas de Condorcet, Essai sur l’application de l’analyse à la probabilité des décisions rendues à la pluralité des voix, 1785. ↩

17. Guneet Kohli, Apple Machine Learning Research, Nine Judges, Two Effective Votes: Correlated Errors Undermine LLM Evaluation Panels, prépublication, mai 2026. ↩ ↩²

18. Jialing Li, Zhouhong Gu, Yin Cai et Hongwei Feng, Scaling Behavior of Single LLM-Driven Multi-Agent Systems, prépublication arXiv, 30 mai 2026. ↩

19. Lingjiao Chen et al., Are More LLM Calls All You Need? Towards the Scaling Properties of Compound AI Systems, NeurIPS 2024. ↩

20. Walden Yan, Cognition, Don’t Build Multi-Agents, 12 juin 2025. ↩

21. Tom Burns et G. M. Stalker, The Management of Innovation, 1961 ; Henry Mintzberg, The Structuring of Organizations, 1979 ; James G. March, Exploration and Exploitation in Organizational Learning, Organization Science, 2(1), 1991. ↩

22. Allen C. Ward, Jeffrey K. Liker, John J. Cristiano et Durward K. Sobek II, The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster, Sloan Management Review, 36(3), 1995 ; Durward K. Sobek II, Allen C. Ward et Jeffrey K. Liker, Toyota’s Principles of Set-Based Concurrent Engineering, Sloan Management Review, 40(2), 1999. ↩

23. Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas, 2009 ; John D. C. Little, A Proof for the Queuing Formula L = λW, Operations Research, 9(3), 1961. ↩

24. Juraj Gottweis et al., Accelerating scientific discovery with Co-Scientist, Nature 655, 487-496, 2026, DOI 10.1038/s41586-026-10644-y. ↩

25. OpenAI, Research acceleration: the view inside OpenAI, 6 septembre 2026. ↩ ↩²

26. OpenAI, How agents are transforming work, 25 juin 2026. ↩

27. Cercle, Quand générer ne coûte plus rien, vérifier devient le problème, 21 août 2026. ↩

28. Cercle, Investir dans le Cercle, sections « Une architecture en quatre éléments » et « Les Compagnons », consulté le 15 septembre 2026. ↩