Superviseur vs agents pairs : quel pattern d'orchestration choisir ?

Dès qu'un système dépasse deux ou trois agents, une question revient : qui décide de qui fait quoi ? Deux architectures dominent.

Le pattern superviseur

Un agent orchestrateur reçoit la tâche, la découpe et délègue à des agents spécialisés (recherche, rédaction, vérification), puis assemble les résultats.

Avantages : comportement prévisible, facile à déboguer (un seul point de décision), coût maîtrisé car chaque sous-agent a un rôle étroit.

Limite : le superviseur devient un goulot d'étranglement si la tâche demande beaucoup d'allers-retours entre sous-agents.

Le pattern agents pairs

Les agents communiquent directement entre eux (via une file de messages ou un tableau partagé), sans chef d'orchestre unique.

Avantages : plus résilient si un agent tombe, mieux adapté aux tâches où la séquence des étapes n'est pas connue à l'avance.

Limite : le débogage est plus dur — il faut tracer les échanges entre agents, pas juste les appels d'un superviseur.

Notre recommandation

Commencez toujours par un superviseur. Ce n'est qu'une fois que vous constatez un vrai goulot d'étranglement (le superviseur devient trop gros, trop de logique conditionnelle) qu'il vaut la peine de basculer vers des agents pairs — la complexité de debug supplémentaire n'est pas gratuite.