Orchestrer des agents IA : le seuil à partir duquel ça devient utile

Un agent qui répond à une question et un système qui orchestre plusieurs agents ne résolvent pas le même problème. Le premier suffit pour l'immense majorité des tâches : lire du code, écrire une fonction, répondre à une question précise. Le second ne devient intéressant qu'à partir d'un seuil de complexité bien identifiable — et le franchir trop tôt coûte plus cher qu'il ne rapporte, en temps de conception comme en tokens dépensés à coordonner plutôt qu'à produire.

Le signal qui justifie l'orchestration

Deux situations, et deux seulement, rendent un orchestrateur pertinent. La première : une tâche se décompose en sous-tâches réellement indépendantes, sans état partagé entre elles. Par exemple :

• relire un diff de pull request sous plusieurs angles à la fois (sécurité, performance, lisibilité) plutôt que d'enchaîner les angles un par un dans la même conversation ;
• chercher l'origine d'une régression en interrogeant les logs par service, par intervalle de temps et par utilisateur simultanément, plutôt que d'épuiser une piste avant d'ouvrir la suivante ;
• auditer cinq modules indépendants d'un même projet, chacun sans dépendance sur ce que trouvent les autres.

Un agent unique qui traite ces angles en boucle séquentielle perd du temps sur des étapes qui n'ont aucune raison de s'attendre les unes les autres. La seconde situation : une réponse a besoin d'être mise à l'épreuve plutôt que produite une fois — trancher un choix d'architecture ambigu en confrontant plusieurs propositions indépendantes, par exemple, plutôt qu'en itérant seul sur une unique piste. Un seul agent qui génère une réponse et la relit lui-même a tendance à se convaincre de sa propre sortie — il manque un regard réellement indépendant. En dehors de ces deux cas, ajouter une couche d'orchestration ne fait qu'ajouter de la latence et de la coordination à gérer, pour un gain nul.

Pipeline plutôt que barrière, par défaut

Une fois l'orchestration justifiée, le premier choix de conception passe souvent inaperçu, alors qu'il change tout : faire avancer chaque élément indépendamment à travers toutes ses étapes (pipeline), ou faire attendre le lot entier à la fin de chaque étape avant de passer à la suivante (barrière) — comme sur une chaîne de montage où une pièce peut soit enchaîner les postes à son propre rythme, soit rester bloquée jusqu'à ce que la pièce la plus lente ait fini le poste en cours.

Avec deux étapes (analyze puis review) appliquées à un lot de modules, la différence tient à une seule ligne :

// Barrière : review ne démarre pour PERSONNE tant qu'analyze n'a pas fini pour TOUT LE MONDE
const analyzed = await Promise.all(modules.map(analyze));
const reviewed = await Promise.all(analyzed.map(review));
 
// Pipeline : chaque module enchaîne ses propres étapes, sans attendre les autres
const reviewed = modules.map((m) => analyze(m).then(review));

Ça ne saute aux yeux que si on regarde ce qui se passe module par module. Prenons cinq modules : quatre petits (analyze = 3 s, review = 2 s, donc 5 s au total chacun) et un gros (analyze = 30 s, review = 2 s, donc 32 s). En pipeline, les quatre petits modules ont leur résultat complet — analysé, relu, prêt à consommer — dès la 5ᵉ seconde ; le gros arrive à 32 s sans avoir ralenti personne. En barrière, review ne peut démarrer pour aucun module tant que les cinq analyze ne sont pas tous terminés, soit 30 s à cause du seul gros module : les quatre résultats des petits modules, pourtant calculables dès la 5ᵉ seconde, restent inutilisables jusqu'à la 32ᵉ. Vingt-sept secondes perdues à attendre un voisin qui n'avait aucun rapport avec eux.

Une barrière reste légitime quand l'étape suivante a réellement besoin de voir tous les résultats à la fois — dédupliquer des découvertes avant une étape coûteuse, ou trancher un score global une fois tous les votes rentrés. Mais par défaut, le réflexe correct est inverse à l'intuition : laisser chaque chaîne avancer seule, et ne synchroniser que là où une dépendance croisée existe vraiment.

La vérification adversariale déplace la notion de confiance

Le changement le plus net qu'apporte un système multi-agents, ce n'est pas la vitesse, c'est la nature de la confiance qu'on peut accorder à un résultat. Un agent seul qui affirme quelque chose ne fait que répéter sa propre conviction. Plusieurs agents indépendants, dont le rôle explicite est de réfuter une affirmation plutôt que de la confirmer, produisent une confiance d'une autre nature : une conclusion qui survit à plusieurs tentatives sincères de la démolir vaut davantage qu'une conclusion jamais mise à l'épreuve.

Concrètement, ça se traduit par un vote à seuil plutôt qu'un simple aller-retour : un correctif proposé passe devant trois vérificateurs indépendants dont le seul mandat est d'y trouver une faille, et il n'est retenu que si au moins deux sur trois échouent à le réfuter. Le vote est délibérément biaisé vers le doute — en cas d'incertitude, un vérificateur doit répondre par le rejet, pas par la validation, sans quoi le mécanisme dérive vers la même complaisance qu'un agent unique qui se relit lui-même. C'est un renversement de posture — on ne demande plus « est-ce que c'est correct ? » à la même instance qui vient de produire la réponse, on demande à d'autres instances d'essayer de prouver le contraire.

Le vrai coût n'est pas le token, c'est la décomposition

Le risque le plus sous-estimé n'est pas financier, c'est architectural : une mauvaise décomposition en sous-tâches coûte plus cher qu'une absence totale d'orchestration. Exemple typique : découper un diagnostic de bug en trois sous-agents, un par couche (frontend, API, base de données), alors que le problème se situe exactement à la frontière entre deux couches. Aucun des trois n'a la moitié manquante du puzzle, et si personne n'est explicitement chargé de recouper les zones de recouvrement, la synthèse finale assemble trois diagnostics partiels et cohérents en apparence, mais faux. Une étape de synthèse oubliée qui laisse des résultats contradictoires sans arbitrage, un fan-out sur une tâche qui n'avait en réalité rien d'indépendant à paralléliser — chacun de ces défauts de conception produit un résultat pire qu'un simple agent qui aurait traité la tâche en séquence, tout en donnant l'illusion d'un système plus sophistiqué. L'orchestration n'est pas un signe de maturité en soi ; elle n'est justifiée que par la forme réelle du problème qu'elle traite.