Chapitre 6 — Stratégies d'orchestration fondamentales

Sixième billet de la tournée chapitre par chapitre de LLM Primer IV : Concevoir la cognition de l'IA avec MCP. Un système multi-agents est un système distribué — une fois ce cadrage accepté, la plupart des choix de conception de ce chapitre deviennent familiers, et la plupart des échecs coûteux de 2024 et 2025 cessent d'être mystérieux.

Pourquoi ce chapitre existe

Le langage marketing autour des systèmes agentiques suggère que plus d'agents est intrinsèquement meilleur — plus de puissance cognitive, plus de spécialisation, plus de capacité émergente. La réalité d'ingénierie est l'inverse, dans la plupart des cas. Chaque agent supplémentaire ajoute un aller-retour, un point de sérialisation, un endroit où la sortie d'un agent devient l'entrée d'un autre, et une nouvelle occasion pour la conversation de partir de travers. La bonne question de départ n'est pas « comment répartir cela entre agents ? » mais « un seul modèle, avec les bons outils, peut-il faire cela en un appel ? »

Ce chapitre parcourt les deux formes d'orchestration les plus simples — séquentielle et concurrente — et la question préalable qui devrait précéder l'une comme l'autre. Beaucoup des échecs de production les plus coûteux des deux dernières années n'étaient pas des échecs d'orchestration. C'étaient des systèmes bâtis comme multi-agents alors qu'un seul agent bien outillé aurait fait le travail avec un dixième de la latence et zéro bug de coordination.

6.1 Quand plusieurs agents aident vraiment

L'argument pour un seul agent avec outils est le plus fort quand la tâche se décompose en un petit nombre d'opérations bien définies sur des sources de données bien définies. Un assistant de revue de code qui lit un diff, lance un linter, consulte des conventions, et écrit un commentaire peut être construit comme une seule invocation de modèle avec quatre outils. Ajouter un second agent introduit de la latence sans ajouter de capacité — le modèle planifie déjà ; un second modèle qui planifie différemment est un coût de coordination, pas une amélioration.

Trois propriétés font payer le multi-agents. Hétérogénéité de contexte — quand deux phases ont besoin de prompts système, d'outils ou de matériel de référence dramatiquement différents, forcer les deux dans une même fenêtre dilue l'attention du modèle. Le cas canonique est rechercher-puis-écrire : la récupération veut de l'ampleur et des outils de recherche, l'écriture veut de la prose et aucun outil. Raffinement itératif contre une vérification externe — si la sortie doit être revue et possiblement réécrite, le producteur et le vérificateur veulent chacun leur propre contexte et leur propre prompt. Parallélisme à travers des sous-tâches indépendantes — cinq sources de documents à résumer, trois perspectives à recueillir, dix fichiers à analyser — les exécuter en série gaspille du temps horloge sur du travail qui n'a aucune dépendance causale.

Avant de s'engager dans le multi-agents, un ingénieur devrait pouvoir nommer la propriété qui le motive. Un rétro de 2025 chez une grande entreprise logistique a remplacé une orchestration de support client à sept agents par un seul agent Claude plus six outils MCP ; la version mono-agent était plus rapide, moins chère, et meilleure sur la qualité de résolution. « Peut-on effondrer ceci ? » devrait être une question debout dans toute revue d'orchestration.

6.2 Orchestration séquentielle : pipelines et raffinement progressif

L'orchestration séquentielle est la forme multi-agents la plus simple. La sortie d'un agent devient l'entrée du suivant. La plupart des systèmes « multi-agents » de production sont des pipelines séquentiels déguisés. La force, c'est la lisibilité : le pipeline peut se dessiner au tableau, se tester étape par étape, et se raisonner comme une suite de contrats entrée-sortie. Le contrat entre étapes est l'artefact clé — chaque étape déclare son schéma d'entrée, l'orchestrateur le fait respecter par du code plutôt que par la confiance, et les échecs de validation déclenchent des retries ou des fallbacks plutôt que de se propager silencieusement.

Le cas canonique est rechercher-puis-écrire. Un agent de recherche avec outils de recherche web et de récupération produit un brief structuré ; un agent rédacteur sans outils et avec un prompt de prose transforme le brief en article. Le rédacteur ne voit pas les faux départs, les sources écartées, ni les longues chaînes de raisonnement. Il voit le brief. Les deux étapes peuvent utiliser des modèles différents — raisonnement fort pour la recherche, prose forte pour l'écriture — et les coûts ne s'accumulent que là où chacun est nécessaire. Le raffinement progressif est un proche cousin : brouillon, édition, vérification factuelle, reformatage. Les opérateurs spécialisés battent un généraliste qui essaie de tout faire en une passe.

Les coûts honnêtes sont au nombre de trois. Latence — un pipeline à N étapes a un plancher égal à la somme des temps d'exécution. Les longs pipelines s'auto-excluent de la latence conversationnelle par définition. Amplification d'erreurs — un pipeline à quatre étapes à 95 % par étape donne 81 % de bout en bout ; à huit étapes, 66 %. La validation par étape avec retries bornés est ce qui garde les calculs opérables. Perte d'information entre étapes — chaque sortie est nécessairement plus étroite que son contexte de travail, et l'information dont l'agent rédacteur s'aperçoit plus tard avoir besoin a disparu, sauf si le schéma du brief était plus riche que strictement nécessaire.

6.3 Orchestration concurrente : scatter, gather, multi-perspectives

L'orchestration concurrente fait tourner plusieurs agents en parallèle et combine leurs sorties. La propriété qui définit, c'est l'absence de dépendance causale pendant le travail — la dépendance n'apparaît qu'à l'étape de combinaison. Parfois appelée scatter-gather, parfois map-reduce pour agents ; la topologie est la même.

Trois cas d'usage motivent le patron. Parallélisme à travers des sous-tâches indépendantes — cinq sources lues en parallèle, puis un synthétiseur. Le temps horloge est celui du lecteur le plus lent plus le synthétiseur, pas la somme. Analyse multi-perspectives — la même entrée donnée à un prompt d'analyste financier, à un prompt de juriste, et à un prompt de stratège produit, avec des cadrages assez vraiment différents pour que les sorties ne soient pas que des variantes cosmétiques. Ensemblage pour la fiabilité — le même prompt sur plusieurs agents avec sorties votées ou moyennées, défendable quand une mauvaise réponse coûte beaucoup plus qu'une facture de tokens multipliée par trois.

L'étape de combinaison est là où l'effort d'ingénierie paie. Des synthétiseurs naïfs auxquels on tend de longues entrées contradictoires deviennent des goulots. Trois patrons l'améliorent : sorties intermédiaires structurées pour que le synthétiseur fusionne les champs de façon déterministe plutôt que de relire de la prose ; réduction hiérarchique pour que chaque agent combinateur voie un nombre borné d'entrées à mesure que le fan-out grandit ; et mise en lumière des conflits pour que le synthétiseur étiquette les désaccords plutôt que de choisir silencieusement un camp.

La question de diagnostic pour savoir si scatter-gather est juste : si je disais à un agent parallèle ce qu'un autre est en train de produire, cela changerait-il sa sortie ? Si oui, le travail n'était pas indépendant et le patron est faux — il vous faut soit des dépendances séquentielles, soit les patrons dynamiques du Chapitre 7.

6.4 Le calcul honnête de la coordination

Chaque patron d'orchestration est, à l'exécution, un workflow distribué sur des travailleurs peu fiables. Des taux d'échec par appel de 1 à 5 % sont typiques même sur des modèles de qualité — échecs de parsing JSON, violations de contrat, noms d'outils hallucinés, sauts silencieux. Multipliés à travers un pipeline, un taux de 2 % par étape sur huit étapes donne 85 % de bout en bout. Les atténuations sont structurelles : validation par étape qui déclenche des retries bornés ; observabilité par étape qui enregistre entrées, sorties, latence, dépense de tokens, et quelles barrières de validation sont passées ; et fallback borné pour qu'un budget de retries épuisé dégrade gracieusement plutôt que d'effondrer tout le flux.

Les budgets de latence ont besoin d'un plafond, pas seulement d'un plancher — les utilisateurs ne se soucient pas de la moyenne, ils se soucient de la longue queue. Les budgets de coût ont besoin d'un modèle a priori : un pipeline à deux étapes coûte environ 1,5 fois un équivalent à une étape, scatter-gather sur cinq branches coûte 5 à 8 fois, les tables rondes 10 fois ou plus. Certains systèmes ne sont pas viables à l'échelle parce que leur coût par interaction dépasse la valeur de l'interaction. Faites l'arithmétique au temps de conception, pas après l'arrivée de la facture.

Ce que prépare le Chapitre 6

Séquentiel et concurrent sont les briques de base. Ils traitent la plupart des cas d'usage multi-agents quand la topologie de la tâche est connue d'avance et que les rôles des travailleurs sont fixés. Ils partagent une hypothèse : quelqu'un, au temps de conception, a décidé quels sont les agents et comment ils se connectent. L'orchestration est statique ; le pipeline est dessiné avant qu'aucune requête utilisateur n'arrive. Le Chapitre 7 retire cette hypothèse.

Prochaine étape — Chapitre 7 : Patrons collaboratifs et dynamiques avancés. Tables rondes, routage par handoff, et orchestration magentique — ce qui se passe quand la topologie doit être bâtie par requête plutôt que par conception, et les modes de défaillance (non-terminaison, mauvais routage, planification emballée) que les patrons plus simples évitent.