Multi-agents et orchestration

Pourquoi passer à plusieurs agents

Un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire unique équipé de function callingtool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire atteint vite ses limites dès que la tâche mélange des compétences hétérogènes : rechercher de l'information, écrire du code, vérifier un résultat, rédiger une synthèse. On peut empiler des instructions dans un seul promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire système, mais le résultat se dégrade : le modèle mélange les rôles, oublie une contrainte formulée trop tôt, ou applique le mauvais registre de sortie au mauvais moment.

L'architecture multi-agents répond à un principe simple : diviser le travail entre plusieurs instances spécialisées, chacune avec un prompt système étroit, un jeu d'outils limité et un critère de sortie clair. Ce n'est pas une question de puissance de calcul supplémentaire — un agent spécialisé sur un périmètre réduit produit des résultats plus fiables qu'un agent généraliste chargé de tout faire, parce que son espace de décision est plus petit et donc plus prévisible.

Cette approche a un coût : latence cumulée, complexité de supervision, risque de désynchronisation entre agents. Elle ne se justifie pas pour toute tâche automatisable par un seul appel d'outil bien conçu.

Ajouter des agents augmente la surface de défaillance (handoffs ratés, conflits d'état, boucles). Le critère de décision n'est pas « est-ce possible de découper » mais « est-ce que chaque sous-tâche a un critère de réussite distinct et vérifiable indépendamment ». Si un seul agent avec plusieurs outils suffit, gardez un seul agent.

Les grands patterns d'orchestration

Superviseur / orchestrateur central

Un agent orchestrateur reçoit la demande, décompose la tâche, et délègue à des agents spécialisés (recherche, rédaction, vérification) en leur transmettant un sous-objectif précis. Il récupère les réponses, arbitre les divergences, et compose la sortie finale. C'est le pattern le plus contrôlable : un seul point de décision, une trace d'exécution linéaire, un point unique où appliquer des garde-fous.

L'inconvénient est que l'orchestrateur devient un goulot d'étranglement cognitif : s'il reçoit trop de contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire brut de chaque sous-agent, il retombe dans le même problème de surcharge qu'un agent unique.

Pipeline séquentiel

Les agents s'enchaînent dans un ordre fixe, chacun consommant la sortie du précédent — recherche puis rédaction puis relecture, par exemple. Ce pattern convient aux tâches dont les étapes sont connues à l'avance et ne nécessitent pas de branchement dynamique. Il est simple à déboguer parce que chaque étape peut être rejouée isolément avec l'entrée figée qu'elle a réellement reçue.

Sa limite : il ne gère pas bien les retours en arrière. Si l'agent de relecture détecte une erreur factuelle en amont, le pipeline doit prévoir explicitement un mécanisme de renvoi, sinon l'erreur se propage jusqu'à la sortie.

Réseau pair-à-pair

Les agents communiquent directement entre eux sans chef d'orchestre unique, chacun pouvant solliciter les autres selon ses besoins. Ce pattern est rarement justifié en production : il rend la traçabilité difficile (qui a décidé quoi, et pourquoi) et multiplie les risques de boucle où deux agents se renvoient la même sous-tâche indéfiniment. Sans limite explicite du nombre d'échanges, un réseau d'agents pairs peut entrer dans une boucle de clarification mutuelle — chacun demandant à l'autre de préciser une consigne déjà donnée. Toujours fixer un budget de tours (par exemple 5 échanges maximum) et un comportement de repli explicite — escalade vers un humain, réponse partielle signalée comme telle — au-delà de ce budget.

Hiérarchie à plusieurs niveaux

Combinaison des patterns précédents : un orchestrateur de haut niveau délègue à des sous-orchestrateurs, eux-mêmes responsables d'un pipeline ou d'un petit réseau d'agents d'exécution. Utile pour des tâches réellement complexes (audit multi-domaine, génération de contenu à grande échelle), mais coûteux à maintenir. Le brief de mise en œuvre doit préciser à quel niveau chaque décision de routage est prise, sinon deux niveaux hiérarchiques finissent par arbitrer la même question de façon incohérente.

Définir des rôles étanches

Un rôle d'agent se définit par trois éléments qui doivent tous être explicites avant le premier appel :

• Le périmètre — ce que l'agent a le droit de faire, formulé en creux : ce qu'il n'a pas le droit de faire est tout aussi important. Un agent de rédaction ne devrait pas avoir accès à un outil d'envoi d'e-mail, même si techniquement rien ne l'en empêche.
• Les outils autorisés — la liste des fonctions exposées à cet agent, jamais l'ensemble des outils du système. Restreindre les outils par rôle est le principal levier pour limiter les dégâts d'une décision erronée.
• Le critère de sortie — le format et les conditions qui rendent une réponse de cet agent exploitable par le suivant (schéma structuré, champs obligatoires, longueur maximale).

Un rôle mal délimité produit un symptôme caractéristique : deux agents traitent la même sous-tâche sans le savoir, ou aucun ne la traite parce que chacun suppose que c'est la responsabilité de l'autre. C'est la version multi-agents du problème classique de responsabilité diffuse — la solution est la même : une matrice explicite qui associe chaque type de sous-tâche à un agent unique et nommé.

Le handoff : anatomie d'un transfert

Le handoff est le moment où un agent transmet la main à un autre. C'est le point de défaillance le plus fréquent des systèmes multi-agents, parce qu'il oblige à condenser un contexte potentiellement long en un paquet d'information exploitable par un agent qui n'a rien vu de l'échange précédent.

Un handoff correctement conçu transmet trois choses distinctement :

1. L'objectif reformulé — pas la conversation brute, mais la tâche telle qu'elle se pose maintenant, compte tenu de ce qui a déjà été fait.
2. L'état pertinent — les décisions déjà prises, les contraintes déjà validées, les donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire déjà collectées. Tout le reste doit être délibérément omis.
3. Le critère d'arrêt — comment l'agent receveur saura que sa part est terminée et à qui il doit rendre la main.

Le moyen le plus fiable d'éviter la dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire de contexte est de structurer le handoff avec un schéma explicite (JSON typé) plutôt que de laisser un agent rédiger un résumé libre à l'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire du suivant. Un résumé en langage naturel peut omettre un champ critique sans que cela se voie ; un schéma avec des champs obligatoires échoue de façon visible si l'information manque.

L'agent de recherche ne transmet pas la transcription de ses dix appels d'outil. Il transmet : {"faits": [...], "sources": [...], "lacunes_identifiees": [...], "date_limite_information": "..."}. L'agent de rédaction ignore tout de la façon dont ces faits ont été trouvés — et n'en a pas besoin.

Un handoff mal conçu se repère à un symptôme précis : l'agent receveur repose des questions déjà répondues en amont, ou reformule une contrainte que l'utilisateur avait donnée trois échanges plus tôt. Si cela arrive systématiquement, le problème n'est presque jamais le modèle — c'est le format du transfert.

Gérer les conflits entre agents

Deux agents peuvent produire des réponses incompatibles pour la même sous-tâche — un agent de recherche affirme une donnée, un agent de vérification la contredit avec une source différente. Un système multi-agents mal conçu laisse cette contradiction se propager silencieusement jusqu'à la sortie finale, où l'utilisateur découvre l'incohérence.

Trois stratégies d'arbitrage, à choisir selon le type de tâche :

• Arbitrage par un agent tiers. Un agent dédié, sans lien avec les deux positions en conflit, tranche sur la base des sources fournies. Fonctionne bien quand le désaccord porte sur un fait vérifiable.
• Arbitrage par règle fixe. Une hiérarchie de confiance définie à l'avance (la vérification l'emporte toujours sur la recherche, par exemple) évite un appel de modèle supplémentaire. Rapide, mais rigide — inadapté si le contexte devrait parfois inverser la priorité.
• Escalade humaine. Au-delà d'un certain niveau de désaccord, ou quand les deux agents citent des sources de qualité équivalente, le système signale l'incertitude plutôt que de trancher arbitrairement.

Si l'agent de rédaction est aussi celui qui décide quelle version de deux faits contradictoires retenir, le biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire de confirmation du modèle envers sa propre sortie précédente fausse l'arbitrage. L'agent qui tranche doit toujours être distinct des agents en désaccord.

Un autre type de conflit, moins visible, porte sur les ressources plutôt que sur les faits : deux agents veulent modifier le même état partagé (un même document, un même enregistrement) en parallèle. La solution n'est pas comportementale mais structurelle : sérialiser les écritures sur un état partagé, ou attribuer la propriété exclusive de chaque portion d'état à un seul agent à la fois.

Mémoire, état et traçabilité

Un système multi-agents distingue généralement deux formes de mémoire. La mémoire de travail est propre à chaque agent : le contexte de sa tâche en cours, effacé une fois le handoff effectué. La mémoire partagée persiste au-delà d'un seul agent — état du projet, décisions validées, contraintes globales — et doit être accessible en lecture par tous les agents concernés, mais idéalement modifiable par un seul à la fois pour éviter les écritures concurrentes.

Avec un seul agent, un journal des appels d'outils suffit à comprendre une décision a posteriori. Avec plusieurs agents, il faut en plus tracer qui a transmis quoi à qui — sans ce fil, un résultat erroné ne permet pas de savoir si le problème vient de la recherche, de la rédaction, d'un handoff dégradé ou d'un arbitrage mal informé. Chaque transfert doit être journalisé avec un horodatage, l'identité de l'émetteur et du receveur, et le contenu exact transmis.

En pratique, ce journal est aussi ce qui permet de rejouer un cas en isolant l'étape défaillante — indispensable pour corriger un système multi-agents sans devoir relancer l'ensemble du pipeline à chaque itération de débogage.

Pièges fréquents et checklist de déploiement

Les défaillances les plus courantes des architectures multi-agents ne viennent presque jamais d'un modèle insuffisamment capable, mais de la coordination :

• Sur-découpageChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire. Créer un agent par micro-tâche multiplie les handoffs et donc les points de perte d'information, sans gain de qualité proportionnel.
• Contexte dupliqué. Transmettre l'intégralité de l'historique à chaque agent plutôt qu'un état condensé, ce qui annule le bénéfice de spécialisation et augmente coût et latence.
• Absence de budget de tours. Un système sans limite explicite d'échanges entre agents peut boucler indéfiniment sur un désaccord mineur.
• Rôles qui se chevauchent. Deux agents capables d'effectuer la même action produisent des résultats incohérents selon celui qui s'en charge en premier.
• Arbitrage confié au mauvais agent. Voir plus haut — l'agent en conflit ne doit jamais être son propre arbitre.

Avant de déployer un système multi-agents, vérifier :

1. Chaque agent a un rôle documenté avec périmètre, outils et critère de sortie.
2. Chaque handoff utilise un format structuré, pas un résumé libre.
3. Un mécanisme d'arbitrage existe et est confié à une entité distincte des parties en conflit.
4. Un budget maximal de tours ou d'échanges est fixé, avec un comportement de repli défini.
5. Chaque transfert est journalisé avec émetteur, receveur et contenu.
6. Le système a été testé sur des cas où deux agents sont volontairement mis en désaccord, pour vérifier que l'arbitrage se déclenche correctement.

Un système multi-agents bien conçu se reconnaît à un critère simple : on peut expliquer, pour n'importe quelle sortie produite, quel agent a pris quelle décision et sur quelle base — sans avoir à relire l'intégralité des échanges internes.