Un seul agent doit-il tout faire ?

Systèmes multi-agents

Introduction — Répartir le travail sans diluer la responsabilité

Marie : Stéphane conteste deux frais liés à des trajets Bikaroo. Il faut vérifier son abonnement Semi-Pro League, les données de trajet, les règles de facturation et les éventuels signaux de fraude. Un seul agent doit-il tout analyser ?
Assistant Bikaroo : Pas nécessairement. Plusieurs agents spécialisés peuvent collaborer, à condition que leurs missions, leurs données, leurs outils et leurs responsabilités restent clairement délimités.

Le chapitre précédent a montré comment un agent conserve une continuité grâce à son état et à sa mémoire. Lorsqu’un dossier mobilise plusieurs expertises, une nouvelle question apparaît : faut-il enrichir un agent unique ou répartir le travail entre plusieurs agents spécialisés ?

Une architecture multi-agents peut améliorer la spécialisation, isoler les permissions et paralléliser certaines analyses. Elle peut aussi multiplier les appels de modèles, les messages, les coûts, les erreurs et les zones grises de responsabilité. Le multi-agent n’est donc pas un niveau de maturité obligatoire. C’est un choix d’architecture qui doit produire un bénéfice mesurable.

Ce que vous allez apprendre

À la fin de ce chapitre, vous pourrez :

• distinguer système multi-agents, agent unique, workflow et ensemble de services ;
• concevoir un coordinateur et des contrats de délégation structurés ;
• organiser le partage du contexte, de l’état et de la mémoire entre agents ;
• gérer contradictions, provenance, propagation des erreurs et responsabilité ;
• évaluer si le bénéfice de la spécialisation justifie réellement la complexité ajoutée.

Comprendre la spécialisation multi-agents

Qu’est-ce qu’un système multi-agents ?

Un système multi-agents contient plusieurs composants agentiques capables de :

• recevoir une mission ;
• prendre des décisions dans un périmètre ;
• utiliser des tools ;
• produire un résultat ;
• transmettre ce résultat à un autre agent.

Exemple :

Utilisateur
 ↓
Agent coordinateur
┌──────────────────────┬──────────────────────┐
↓                      ↓                      ↓
Agent relation membre  Agent facturation      Agent conformité

Les agents peuvent communiquer :

• directement ;
• via un coordinateur ;
• via un espace d’état partagé ;
• via des événements ;
• via des messages structurés.

Pourquoi spécialiser les agents ?

Exemple :

Agent facturation
Tools :
- get_invoice
- calculate_refund
- create_refund_request

Interdictions :
- modifier un contrat
- changer une identité

La spécialisation réduit :

• la surface d’action ;
• le nombre de tools ;
• la complexité du prompt ;
• les risques de confusion.

Elle peut également permettre d’utiliser :

• un modèle différent ;
• un corpus RAG différent ;
• des règles de sécurité différentes ;
• des métriques spécifiques.

Le rôle du coordinateur

Un coordinateur reçoit l’objectif global et répartit le travail.

Exemple :

Objectif :
Analyser une contestation de facturation.

Le coordinateur peut demander :

Agent abonnement
→ vérifier les conditions contractuelles

Agent facturation
→ vérifier les montants

Agent conformité
→ vérifier les obligations

Agent relation membre
→ préparer une réponse

Le coordinateur doit ensuite :

• collecter les résultats ;
• détecter les contradictions ;
• décider si des informations manquent ;
• produire ou faire produire la synthèse.

Coordination centralisée ou décentralisée

Une fois que plusieurs agents spécialisés interviennent, il ne suffit plus de décider qui fait quoi. Il faut aussi décider comment les échanges sont organisés.

Deux grandes options existent. Dans une coordination centralisée, un coordinateur garde la vision d’ensemble, distribue les tâches et rassemble les résultats. Dans une coordination décentralisée, les agents peuvent se transmettre directement des messages ou des sous-tâches.

Le choix a des conséquences importantes : visibilité, audit, contrôle, parallélisme, coût, risque de boucle et clarté de la responsabilité. Le sujet n’est donc pas seulement technique. Il touche à la gouvernance du système multi-agents.

Coordination centralisée

Un agent coordinateur contrôle les échanges.

Avantages :

• visibilité ;
• audit ;
• contrôle ;
• ordre clair.

Risques :

• goulot d’étranglement ;
• dépendance centrale ;
• contexte important.

Coordination décentralisée

Les agents se transmettent directement les tâches.

Avantages :

• flexibilité ;
• parallélisme.

Risques :

• boucles ;
• responsabilités floues ;
• duplication ;
• audit difficile.

Organiser la collaboration

Une fois la coordination choisie, il faut organiser la collaboration concrète entre les agents. C’est souvent là que les systèmes multi-agents deviennent difficiles à comprendre : chaque agent peut sembler « intelligent », mais l’ensemble peut devenir fragile si les missions, les informations partagées et les responsabilités ne sont pas explicites.

Cette section répond donc à trois questions pratiques :

que délègue-t-on ?
que partage-t-on ?
comment consolide-t-on les résultats ?

Délégation et contrat de délégation

Une délégation doit être structurée. Le coordinateur ne doit pas simplement demander à un agent spécialisé de « regarder le dossier ». Il doit lui transmettre une mission claire, les données utiles, les limites à respecter et la forme attendue du résultat.

Exemple :

{
  "task": "verify_refund_eligibility",
  "memberId": "MBR-1842",
  "transactionIds": ["T-1", "T-2"],
  "constraints": {
    "doNotExecuteRefund": true
  },
  "expectedOutput": {
    "eligible": "boolean",
    "reasons": "array"
  }
}

Le contrat précise :

• la tâche ;
• les données ;
• les limites ;
• la sortie attendue ;
• les actions interdites.

Une phrase vague comme :

Regarde ce dossier et dis-moi ce que tu en penses.

augmente l’ambiguïté.

Partage du contexte

Tous les agents n’ont pas besoin de voir tout le dossier. L’agent facturation peut avoir besoin des montants et transactions ; l’agent conformité peut avoir besoin des règles applicables ; l’agent relation membre peut avoir besoin d’un résumé compréhensible pour préparer une réponse.

Tout partager

Avantage :

• contexte complet.

Risques :

• coût ;
• fuite de données ;
• bruit ;
• perte de séparation.

Partage minimal

Chaque agent reçoit uniquement les informations nécessaires.

Avantages :

• moindre privilège ;
• contexte plus court ;
• meilleure spécialisation.

Le coordinateur peut transmettre :

résumé
identifiants
données utiles
contraintes

sans envoyer l’intégralité du dossier.

Mémoire partagée ou séparée

Le même raisonnement s’applique à la mémoire. Si plusieurs agents participent au même dossier, faut-il leur donner accès à un espace commun, ou conserver une mémoire séparée pour chaque spécialité ?

Une mémoire partagée facilite la cohérence, mais augmente les risques de contamination et d’accès excessif. Une mémoire séparée isole mieux les responsabilités, mais peut créer des doublons ou des divergences. Le choix dépend donc de ce que l’on veut partager : l’état métier officiel, les observations utiles, ou les souvenirs propres à chaque agent.

Mémoire partagée

Tous les agents consultent un même état.

Avantage :

• cohérence.

Risque :

• contamination ;
• concurrence ;
• accès excessif.

Mémoire séparée

Chaque agent possède son espace.

Avantage :

• isolation.

Risque :

• duplication ;
• divergences.

Une approche hybride peut utiliser :

état métier central
+
mémoire spécialisée par agent

Résoudre les contradictions

La spécialisation augmente la qualité de l’analyse, mais elle peut aussi produire des conclusions différentes. Ce n’est pas forcément une erreur : deux agents peuvent regarder le même dossier avec des critères différents.

EN PRATIQUE

Dans le cas de Stéphane, l’agent abonnement peut conclure qu’une régularisation est possible, tandis que l’agent conformité peut exiger une validation supplémentaire. Le système doit alors savoir comment arbitrer, au lieu de fusionner les réponses de manière naïve.

Exemple :

Agent abonnement :
Le remboursement est autorisé.

Agent conformité :
Une validation supplémentaire est requise.

Le coordinateur ne doit pas improviser une moyenne.

Il doit appliquer :

• une règle de priorité ;
• une hiérarchie d’autorité ;
• une escalade ;
• une validation humaine.

Parallélisme

L’un des intérêts du multi-agent est de pouvoir traiter certaines analyses en parallèle. Mais le parallélisme n’est utile que si les tâches sont réellement indépendantes et si le coordinateur sait ensuite rassembler les résultats dans le bon ordre.

Plusieurs tâches indépendantes peuvent être exécutées en parallèle.

vérification abonnement ──┐
vérification paiement ────┼→ synthèse
vérification fraude ──────┘

Avantages :

• réduction du temps.

Risques :

• charge ;
• coût ;
• résultats arrivant dans un ordre différent ;
• difficulté de corrélation.

Contrôler la chaîne de décision

Dans un système multi-agents, une décision ne vient plus d’un seul composant. Elle se construit parfois par étapes : un agent analyse, un autre complète, un troisième synthétise, puis le coordinateur prépare une conclusion.

Cette chaîne peut être utile, mais elle peut aussi amplifier une erreur. Une information mal interprétée au début peut devenir plus crédible à chaque transmission si personne ne vérifie sa provenance. Il faut donc contrôler non seulement le résultat final, mais aussi le chemin suivi pour y arriver.

Propagation des erreurs

Une erreur d’un agent peut devenir l’entrée d’un autre.

Agent A invente un montant
→ Agent B calcule une indemnité
→ Agent C rédige une réponse

Contrôles utiles :

• sorties structurées ;
• provenance ;
• validation ;
• confiance ;
• accès direct à la source de vérité ;
• refus de transmettre une donnée non vérifiée.

Coût et latence

Un système multi-agents peut multiplier :

nombre d'agents
× nombre d'étapes
× taille du contexte

Il faut mesurer :

• tokens ;
• appels ;
• temps ;
• taux de succès ;
• valeur de la spécialisation.

Un agent unique avec de bons tools peut parfois être supérieur.

Responsabilité

Pour chaque décision, il faut pouvoir répondre :

quel agent ?
quel modèle ?
quelle instruction ?
quelles sources ?
quels tools ?
quelle validation ?

Choisir le bon modèle d’architecture

Après avoir vu les agents spécialisés, la coordination, le partage du contexte et les risques de propagation, il reste une question très simple : a-t-on vraiment besoin de plusieurs agents ?

Le bon modèle n’est pas celui qui paraît le plus avancé. C’est celui qui résout le problème avec le niveau de complexité le plus raisonnable. Dans certains cas, un workflow suffit. Dans d’autres, un agent unique avec de bons outils est plus lisible. Le multi-agent ne devient intéressant que lorsque la spécialisation, l’isolation des droits ou le parallélisme apportent un bénéfice clair.

Agent, service ou workflow ?

Il faut éviter de mettre le mot « agent » sur tous les composants.

Un service ou un microservice expose généralement une capacité stable :

calculer un montant
retrouver une facture
vérifier un statut

Un workflow organise des étapes connues :

classer la demande
calculer
faire valider
notifier

Un agent poursuit un objectif dans un périmètre borné, observe les résultats et peut adapter la prochaine action.

service
→ exécute une capacité

workflow
→ enchaîne des étapes prévues

agent
→ choisit une prochaine action dans un cadre contrôlé

Un modèle spécialisé n’est pas nécessairement un agent

Un composant spécialisé n’est pas automatiquement un agent. Un générateur d’image, un moteur vocal ou un classificateur peuvent être de simples outils.

LLM
+ générateur d'image
+ moteur vocal
+ générateur vidéo

Cette architecture utilise plusieurs modèles, mais elle n’est pas nécessairement multi-agents.

Pour parler d’agent, le composant doit recevoir un objectif, observer un contexte, choisir des actions, adapter son traitement et s’arrêter selon une condition définie.

generate_image
→ outil ou modèle spécialisé

agent de communication
→ poursuit un objectif
→ choisit les livrables
→ appelle plusieurs outils
→ évalue les résultats

Cette distinction évite de confondre architecture multi-modèles et architecture multi-agents.

Exemple : contestation complexe

Dans le scénario Bikaroo, le multi-agent peut se justifier si le dossier de Stéphane demande réellement plusieurs expertises séparées : relation membre, abonnement, paiement, fraude et conformité.

Agent coordinateur
 ↓
Agent relation membre
→ identifie le dossier

Agent abonnement
→ analyse les clauses

Agent paiement
→ analyse les transactions

Agent fraude
→ recherche les signaux

Agent conformité
→ vérifie les obligations

Coordinateur
→ rassemble
→ détecte les écarts
→ soumet à un analyste

Ce déroulement suppose que les cinq analyses convergent. Elles peuvent aussi se contredire.

Agent abonnement
→ la régularisation est due

Agent fraude
→ motif d’attention sur le même trajet

Aucune règle de priorité ne tranche ici. Ce ne sont pas deux réponses à une même question : l’un juge une clause contractuelle, l’autre un faisceau d’indices. Le coordinateur ne peut donc ni choisir, ni fusionner.

Il serait facile de programmer une préférence — la conformité l’emporte toujours, ou le membre bénéficie du doute. Mais cette règle déciderait à la place de l’entreprise, sur un cas que personne n’a examiné.

Une règle de priorité écrite pour éviter un blocage devient une politique d’entreprise que personne n’a validée.

Le coordinateur transmet donc les deux analyses, leurs sources et leur désaccord :

Dossier CASE-1842
Analyse 1 : régularisation due — clause 4.2, abonnement Semi-Pro League
Analyse 2 : motif d’attention — trois trajets similaires en dix jours
Désaccord : non arbitrable par règle
Décision attendue : analyste habilité

puis il s’arrête. Un désaccord entre agents n’est pas une panne : c’est une information à transmettre, pas un écart à lisser.

Critères de décision

La question pratique n’est pas : « peut-on mettre plusieurs agents ? » La bonne question est : « qu’est-ce que plusieurs agents apportent que l’on ne peut pas obtenir plus simplement ? »

Un système multi-agents est justifié si :

• les domaines sont réellement distincts ;
• les outils et permissions doivent être séparés ;
• certaines tâches peuvent être menées en parallèle ;
• chaque sous-tâche produit un résultat clair ;
• le gain dépasse le coût de coordination ;
• la responsabilité reste lisible.

Il est probablement inutile si :

• le processus est court ;
• un seul agent peut tout faire de manière contrôlée ;
• les agents utilisent les mêmes outils et les mêmes données ;
• la coordination devient plus complexe que le problème initial ;
• l’audit devient illisible.

Éviter les anti-patterns

Les anti-patterns suivants sont des signaux d’alerte. Ils montrent que l’architecture multi-agents risque de devenir plus complexe, plus coûteuse ou moins contrôlable que le problème qu’elle devait résoudre.

Ils ne signifient pas que le multi-agent est à éviter en général. Ils rappellent simplement qu’un système multi-agents doit rester gouverné : chaque agent doit avoir une mission utile, des limites claires, une sortie attendue et une responsabilité identifiable.

Agent par micro-tâche

Découper chaque petite opération en un agent distinct peut donner une impression de spécialisation, mais chaque frontière supplémentaire crée des messages, des appels de modèles, de la sérialisation d’état et de nouveaux points de défaillance.

Un traitement simple finit alors par nécessiter plusieurs échanges entre agents avant de produire un résultat. La latence et le coût augmentent, tandis que la responsabilité se fragmente : lorsqu’une erreur apparaît, il devient plus difficile d’identifier quel agent devait réellement la prévenir. Un agent supplémentaire n’est utile que s’il porte une mission suffisamment autonome pour justifier cette nouvelle frontière.

Débat infini entre agents

Deux agents peuvent être conçus pour se critiquer, se vérifier ou améliorer mutuellement leurs propositions. Sans règle d’arrêt, budget ou critère de décision, cette boucle peut cependant continuer sans produire davantage de valeur.

Le risque n’est pas seulement financier. Le système peut accumuler de la latence, produire des arguments contradictoires et rester incapable de transformer le débat en décision. Toute collaboration itérative doit donc posséder une condition d’arrêt et une autorité claire pour conclure.

Coordinateur omniscient

Un coordinateur qui reçoit toutes les données et possède tous les droits simplifie parfois la conception initiale : il peut tout voir et tout déléguer. Mais il concentre alors précisément les privilèges que la spécialisation des agents devait permettre de limiter.

Une erreur de routage, une prompt injection ou une compromission de ce coordinateur peut ainsi exposer plusieurs domaines à la fois. Le coordinateur doit disposer des informations et capacités nécessaires à la coordination, pas automatiquement de l’ensemble des données et permissions de tous les agents spécialisés.

Pas de contrat structuré

Si un agent délègue une tâche à un autre uniquement au moyen d’un message libre, chacun doit interpréter ce que l’autre voulait dire : quelle action est demandée, quelles données sont obligatoires, quelle forme de résultat est attendue et comment signaler une erreur.

Cette ambiguïté rend les échanges difficiles à valider, à rejouer et à tester. Des contrats structurés permettent au contraire de vérifier les entrées et sorties et de détecter une délégation invalide avant qu’elle ne se propage au reste du processus.

Pas de source de vérité commune

Des agents spécialisés peuvent conserver des contextes ou mémoires différents, mais ils ne doivent pas chacun créer leur propre version des faits opérationnels. Si l’agent abonnement croit que le compte est actif tandis que l’agent facturation travaille avec une copie plus ancienne indiquant le contraire, leurs conclusions peuvent diverger tout en semblant localement cohérentes.

Les données faisant autorité doivent donc rester dans des systèmes de référence identifiés. Les agents peuvent en conserver des vues temporaires ou des références, mais ils doivent pouvoir revenir à une vérité commune lorsqu’une décision métier en dépend.

Anthropomorphisme

Donner à des agents des noms, des rôles ou des personnalités peut rendre un diagramme ou une démonstration plus intuitif. Mais une personnalité ne définit ni les données accessibles, ni les tools autorisés, ni le contrat d’échange, ni la responsabilité en cas d’erreur.

Le risque est de croire que « l’agent fraude », « l’agent support » ou « l’agent finance » constitue déjà une architecture simplement parce que leurs rôles semblent naturels à un humain. Les frontières doivent être justifiées par des responsabilités, des permissions et des interfaces explicites, pas seulement par une métaphore organisationnelle.

En résumé

• Objectif global — reçu par le coordinateur, seul à en avoir la vue d’ensemble.
• Sous-objectifs structurés — un contrat de délégation par agent : tâche, données, limites, actions interdites et sortie attendue.
• Agents spécialisés et humain — chacun dans son périmètre, avec ses outils, ses droits et son corpus.
• Résultats avec provenance — sources, confiance et limites, pour qu’une erreur ne gagne pas en crédibilité à chaque transmission.
• Règles de consolidation — priorité, hiérarchie d’autorité, escalade ou validation humaine ; jamais une moyenne improvisée.
• Résultat global — soumis à un responsable autorisé, dont la décision reste humaine.

Le message essentiel est :

Vérifiez votre compréhension

Question 1 — Quel est le rôle du coordinateur ?

Réponse : Il reçoit l’objectif global, le découpe en sous-objectifs et délègue chacun à un agent spécialisé au moyen d’un contrat structuré. Il collecte ensuite les résultats, détecte les contradictions, repère ce qui manque et produit ou fait produire la synthèse.

Question 2 — Pourquoi structurer la délégation ?

Réponse : Parce qu’une demande vague — « regarde ce dossier et dis-moi ce que tu en penses » — laisse l’agent choisir lui-même son périmètre, ses sources et la forme de sa réponse. Le contrat fixe la tâche, les données, les limites, les actions interdites et la sortie attendue.

Question 3 — Quel contexte partager ?

Réponse : Le minimum nécessaire à la mission de chaque agent et autorisé par ses droits : un résumé, les identifiants, les données utiles et les contraintes. Tout partager coûte plus cher, expose davantage de données et dilue la spécialisation qui justifiait la séparation.

Question 4 — Comment résoudre une contradiction ?

Réponse : En appliquant une règle explicite : priorité, hiérarchie d’autorité, escalade ou validation humaine. Le coordinateur ne doit pas improviser une moyenne entre deux analyses ; les agents fournissent des analyses, la gouvernance décide de leur poids.

Question 5 — Pourquoi la provenance est-elle essentielle ?

Réponse : Parce que dans une chaîne d’agents, la sortie de l’un devient l’entrée du suivant. Sans provenance, une erreur commise au premier maillon gagne en crédibilité à chaque transmission, jusqu’à devenir indiscernable d’un fait vérifié.

Question 6 — Quelle différence existe entre agent et microservice ?

Réponse : Un service expose une capacité stable et l’exécute à l’identique à chaque appel. Un agent poursuit un objectif dans un périmètre borné, observe les résultats et adapte sa prochaine action. Un service appelé par un LLM reste un service.

Question 7 — Quand un workflow suffit-il ?

Réponse : Lorsque les étapes sont connues à l’avance et que leur enchaînement ne dépend pas d’observations imprévues. Le workflow est alors plus lisible, plus prévisible et moins coûteux qu’une coordination d’agents.

Question 8 — Quels coûts ajoute le multi-agent ?

Réponse : Ils se multiplient plutôt qu’ils ne s’additionnent : nombre d’agents, par nombre d’étapes, par taille du contexte. S’y ajoutent la latence de coordination, la difficulté de l’audit et le temps passé à corréler des résultats qui n’arrivent pas dans l’ordre attendu.

Question 9 — Comment éviter la propagation des erreurs ?

Réponse : Par des sorties structurées, une provenance conservée à chaque étape, un score de confiance, des validations déterministes, un accès direct à la source de vérité et le refus de transmettre une donnée non vérifiée.

Question 10 — Quels critères justifient l’architecture ?

Réponse : Des domaines réellement distincts, des outils et des permissions à séparer, des tâches parallélisables, des sous-résultats clairs, un gain supérieur au coût de coordination et une responsabilité qui reste lisible. Si l’un de ces critères manque, un agent unique ou un workflow est probablement préférable.

Transition vers le chapitre suivant

La spécialisation peut réduire la surface d’action de chaque agent, mais elle multiplie aussi les échanges, les identités, les outils, les données partagées et les frontières de confiance. Plus le système gagne en capacités, plus il doit rendre explicite ce qui peut être lu, proposé, transmis et exécuté.

La question suivante devient donc : un document, un message ou le résultat d’un autre agent peut-il modifier les règles auxquelles le système doit obéir ?

Le chapitre suivant sera :

Chapitre 12 — Ce document peut-il donner des ordres à l’IA ?

Sécurité, identité et gouvernance

Nous verrons comment donner des capacités à une solution d’IA sans transférer au LLM l’autorité de décider ce qui est permis.