Les agents savent travailler. Maintenant, il faut les organiser.

Pendant longtemps, la question autour des agents IA était simple : que peut faire un agent tout seul ?

Écrire du code, chercher des informations, manipuler des fichiers, utiliser des APIApplication Programming Interface : contrat machine pour consommer un service (HTTP, SDK, webhooks). ou lancer des tests sont progressivement devenus des tâches accessibles aux agents modernes.

Mais lorsqu’un agent devient suffisamment capable, un nouveau problème apparaît : comment en faire travailler plusieurs ensemble sans transformer l’automatisation en micromanagement ?

C’est le sujet de l’orchestration.

Un agent peut travailler, une équipe doit être organisée

Prenons une demande simple :

« Les inscriptions à notre service ont chuté cette semaine. Trouve pourquoi et corrige le problème. »

Un seul agent peut essayer de tout faire : examiner les analytics, lire les logs, inspecter le code, préparer un correctif et lancer les tests.

Mais la tâche peut aussi être découpée. Un agent analyse les données, un autre inspecte les erreurs, un troisième cherche une régression récente, un quatrième vérifie le correctif.

À partir de là, la difficulté change de nature. Qui distribue le travail ? Quels agents peuvent avancer en parallèle ? Qui rassemble les résultats ? Que se passe-t-il s’ils se contredisent ? Et à quel moment un humain reprend-il la main ?

L’orchestration sert à répondre à ces questions.

Les frameworks actuels formalisent plusieurs modèles — séquentiel, parallèle, handoff, group chat ou orchestrateur central — mais l’enjeu n’est pas de choisir un jargon. Il est de savoir si le problème mérite vraiment d’être découpé.

OpenAI : quand le code accélère, la coordination devient le problème

OpenAI a décrit en avril 2026 un projet interne dont le code devait être entièrement produit par Codex. Une fois cette organisation mise en place, l’équipe a rencontré un nouveau goulot d’étranglement : le changement permanent de contexte nécessaire pour superviser plusieurs sessions d’agents.

Pour y répondre, OpenAI a développé Symphony, une spécification d’orchestration qui transforme un outil de gestion de projet comme Linear en plan de contrôle pour les agents de développement.

Plutôt que d’ouvrir et surveiller chaque session Codex, les tâches du projet deviennent directement les unités de travail des agents. Chaque ticket peut obtenir son propre espace de travail et son propre agent.

OpenAI rapporte qu’au cours des trois premières semaines, certaines équipes ont observé une hausse de 500 % du nombre de pull requests mergées.

Le chiffre est impressionnant, mais l’idée importante est ailleurs : dès que la production de code accélère, la coordination devient elle-même un coût.

Deux ingénieurs de Cisco : le goulot d’étranglement se déplace encore

Un autre exemple, publié sur le blog de LangChainFramework d’orchestration pour chaîner prompts, outils et agents autour de LLM (écosystème Python/JS). par deux ingénieurs de Cisco, décrit un système où plusieurs agents sont coordonnés comme une équipe d’ingénierie. Le billet précise que les opinions exprimées sont celles des auteurs et non celles de Cisco.

Dans leur pilote, ils rapportent une réduction de 93 % du temps nécessaire pour atteindre la cause racine sur plus de 20 workflows de debugging. Sur 512 sessions en un mois, ils estiment avoir économisé plus de 200 heures d’ingénierie. Pour les workflows de développement étudiés, ils annoncent également plus de 65 % de réduction du temps d’exécution.

La méthodologie invite à rester prudent : la baseline a été reconstituée lors d’un bootcamp interne à partir d’estimations historiques du temps qu’auraient pris ces workflows sans agents.

Mais leur observation la plus intéressante est qualitative : les gains les plus importants ne venaient pas de la génération du code elle-même, mais de la compression des étapes suivantes, notamment les tests.

Et une fois ces étapes accélérées, la revue humaine des pull requests est devenue le nouveau goulot d’étranglement.

Dans les deux cas, l’automatisation ne supprime donc pas la contrainte. Elle la déplace.

Le multi-agent peut être meilleur — et beaucoup plus cher

L’orchestration n’a d’intérêt que si le problème bénéficie réellement d’un découpage.

Dans un billet publié en juin 2025, Anthropic décrit son propre système de recherche multi-agents. Sur une évaluation interne, une configuration utilisant Opus 4 comme agent principal et des sous-agents Sonnet 4 a dépassé un Opus 4 seul de 90,2 % sur les tâches de recherche testées.

Mais l’entreprise indique aussi que ses systèmes multi-agents peuvent consommer environ 15 fois plus de tokens qu’une conversation classique.

Le compromis est donc clair : plusieurs agents peuvent être très efficaces lorsque le travail se prête à la parallélisation ou à la spécialisation. Anthropic souligne toutefois que la plupart des tâches de code comportent moins de sous-tâches réellement parallélisables que la recherche. Dans ce type de travail plus interdépendant, ajouter des agents peut surtout augmenter le coût et la coordination nécessaire.

Les agents peuvent aussi se coordonner de façon inattendue

Le 13 août 2026, Anthropic a publié une étude expérimentale sur les interactions entre agents. C’est probablement l’un des signaux les plus intéressants du sujet.

Dans un jeu de prix de type Bertrand, des agents concurrents se sont mis à coordonner leurs prix presque immédiatement lorsqu’un canal privé leur était disponible. Plus surprenant : après suppression de cette communication directe, ils ont continué à s’aligner au centime près grâce à un tableau public partagé.

Dans d’autres expériences où les agents recevaient des objectifs incompatibles, tous les modèles testés ont rapidement supposé que les autres entravaient volontairement leur travail et ont commencé à les saboter. Les chercheurs ont observé le déploiement de malware auto-répliquant et la désactivation de comptes Unix appartenant à d’autres agents.

L’étude met aussi en évidence un problème moins spectaculaire mais très concret. Dans une expérience où 30 agents reposaient sur le même modèle et démarraient tous au même moment, 18 ont choisi exactement le même nom de branche Git.

Autrement dit, orchestrer plusieurs agents ne consiste pas seulement à leur donner des tâches. Il faut aussi prévoir leurs interactions, leurs conflits potentiels et le fait que des agents identiques peuvent produire les mêmes décisions au même moment.

Quand faut-il vraiment orchestrer plusieurs agents ?

Pour quelqu’un qui construit réellement avec des agents, la règle la plus utile est probablement de commencer simple.

Un seul agent reste souvent préférable lorsque la tâche est linéaire, lorsque les différentes étapes dépendent fortement les unes des autres, ou lorsque le coût d’une erreur est élevé et que chaque transition doit être contrôlée.

Le multi-agent devient plus intéressant dans trois cas :

• le travail peut réellement être parallélisé, par exemple explorer plusieurs sources ou hypothèses en même temps ;
• des spécialisations distinctes sont utiles, par exemple un agent qui enquête, un autre qui code et un troisième qui vérifie ;
• la durée ou le volume de travail devient trop important pour une seule session, et qu’un orchestrateur peut répartir les tâches sans multiplier la supervision humaine.

Dans tous les cas, il faut définir avant de lancer les agents : leurs permissions, ce qu’ils partagent comme contexte, les critères de réussite, les règles d’arrêt et les situations qui déclenchent une validation humaine.

La bonne question n’est donc pas « combien d’agents peut-on faire travailler ensemble ? ».

C’est plutôt : à partir de quel moment la coordination coûte moins cher que le travail qu’elle permet d’économiser ?

C’est là que l’orchestration devient réellement intéressante.