L’orchestration des agents IA est la coordination de plusieurs agents IA spécialisés, et des personnes qui travaillent avec eux, pour qu’une demande client atteigne le bon agent au bon moment avec le bon contexte. Un orchestrateur, soit un agent principal, soit le code qui entoure les agents, décide qui agit ensuite, ce qui est transmis et quand le travail est terminé.
En bref
- L’orchestration décide quel agent traite chaque étape d’une conversation, quel contexte il reçoit et quand une personne prend le relais.
- La plupart des dispositifs de support combinent quelques modèles : un routeur ou un superviseur en entrée, des étapes séquentielles pour les actions encadrées, et des transferts entre agents et vers des personnes.
- Les conversations multi-agents cassent aux jonctions : contexte perdu lors d’un transfert, boucles entre agents, mauvais agent qui agit, conversations clôturées avant que le travail soit fait.
- Les tableaux de bord par agent masquent ces défaillances, car chaque agent peut sembler irréprochable alors que le parcours du client échoue.
- Contrôlez le parcours, pas l’échange : rassemblez chaque segment, agent ou humain, dans un seul enregistrement, évaluez les jonctions et attribuez chaque défaillance au segment qui l’a causée.
Qu’est-ce que l’orchestration des agents IA ?
L’orchestration des agents IA est la couche qui coordonne plusieurs agents IA au sein d’un même système. IBM la décrit comme la coordination d’agents spécialisés vers des objectifs communs, avec un orchestrateur qui peut être un agent central ou un framework. Au service client, elle transforme un bot de tri, un agent facturation, un agent retours et votre équipe humaine en une seule expérience.
Un agent IA (en anglais) est un modèle doté d’instructions et d’outils, qui travaille vers un objectif. L’orchestration est le contrôle du trafic entre plusieurs d’entre eux ; elle répond à quatre questions à chaque tour :
- Qui agit ensuite ? Un agent de tri, un spécialiste, une personne, ou personne (la conversation est terminée).
- Que reçoit-il ? La transcription complète, un résumé, ou seulement les champs dont il a besoin.
- Qu’a-t-il le droit de faire ? Lire des données, modifier une commande, émettre un remboursement, ou seulement répondre.
- Quand cela s’arrête-t-il ? L’objectif est atteint, une limite de tours est atteinte, ou une personne doit valider.
Anthropic appelle workflows les systèmes où « les LLM et les outils sont orchestrés selon des chemins de code prédéfinis », et agents les systèmes où les modèles « dirigent eux-mêmes, de façon dynamique, leurs processus et leur usage des outils » (notre traduction). La plupart des orchestrations de support mélangent les deux : des chemins fixes pour les remboursements et les vérifications d’identité, le jugement de l’agent pour les questions ouvertes. Notre article sur ce qu’est l’IA agentique (en anglais) couvre la catégorie plus large.
Qui est l’orchestrateur IA ? Sur le plan technique, le composant (un agent principal ou un framework) qui répartit le travail. Sur le plan organisationnel, la personne ou l’équipe responsable de la façon dont agents et humains se partagent le travail : règles de routage, déclencheurs d’escalade et standard de qualité pour le parcours complet.
Quels sont les principaux modèles d’orchestration des agents IA ?
Une poignée de modèles couvre presque tous les dispositifs de support : un routeur qui envoie chaque demande à un spécialiste, un superviseur qui garde la main et appelle des spécialistes comme des outils, une séquence fixe d’étapes, des agents parallèles qui travaillent sur la même entrée, une hiérarchie de superviseurs, des transferts entre agents et vers des humains, et une boucle rédacteur-vérificateur. Les déploiements réels les combinent.
Les éditeurs les nomment différemment. Le Centre des architectures Azure de Microsoft cite l’orchestration séquentielle, simultanée, en conversation de groupe, par transfert et magentique et note que le transfert est aussi appelé routage, tri, transfert, répartition ou délégation. Le SDK OpenAI Agents (en anglais) distingue les « agents as tools », où un agent gestionnaire garde la main, des « handoffs », où le spécialiste prend le relais. IBM ajoute les modèles centralisé, décentralisé, hiérarchique et fédéré. Les mots changent ; les questions du support, non. Le tableau ci-dessous décrit chaque modèle en termes de support.
La distinction la plus importante pour un responsable support est à qui appartient le client après le changement. Dans un dispositif à superviseur, l’agent principal reste responsable de la réponse finale. Dans un transfert, l’agent qui reçoit prend l’entière responsabilité, comme le précise la documentation de Microsoft sur le transfert. C’est ce qui détermine qui vous tenez pour responsable quand le contrôle qualité trouve une mauvaise réponse.
Le tableau des modèles d’orchestration : défaillances et contrôles pour le support
Chaque modèle d’orchestration échoue à sa manière ; chacun demande donc son propre contrôle. Le tableau associe chaque modèle à un exemple de support, à la défaillance à prévoir et à ce qu’il faut regarder lors de la relecture. Copiez-le dans votre plan de contrôle qualité et gardez les lignes qui correspondent à la façon dont vos agents sont reliés aujourd’hui.
| Modèle | Fonctionnement | Exemple au support | Défaillance type | Ce qu’il faut vérifier |
|---|---|---|---|---|
| Routeur (tri) | Un agent de tri classe la demande et la confie à un spécialiste | « Où en est mon remboursement ? » part vers l’agent Facturation | Mauvais routage : l’agent Commandes répond avec assurance à une question de facturation | Le premier routage était-il juste ? Le spécialiste est-il resté dans son périmètre ? |
| Superviseur (gestionnaire) | Un agent principal garde la conversation et appelle des spécialistes comme des outils | L’agent principal demande à l’agent Règles si un retour tardif est autorisé | L’agent principal ignore ou réécrit la réponse d’un spécialiste ; le client reçoit un mélange des deux | La réponse finale correspond-elle à ce que le spécialiste a renvoyé ? |
| Séquentiel (pipeline) | Des étapes fixes, chacune utilisant le résultat de la précédente | Vérifier l’identité, contrôler l’éligibilité, émettre le remboursement, envoyer un récapitulatif | Une erreur en amont se propage à chaque étape (un mauvais numéro de commande mène au mauvais remboursement) | Le résultat de chaque étape a-t-il été validé avant que l’étape suivante l’utilise ? |
| Simultané (parallèle) | Plusieurs agents travaillent en même temps sur le même message | La rédaction de la réponse et un contrôle des règles tournent côte à côte | Des résultats contradictoires mal fusionnés ; le client voit deux réponses | Quand les agents étaient en désaccord, lequel l’a emporté, et était-ce la bonne règle ? |
| Hiérarchique | Des superviseurs gèrent des équipes d’agents par domaine | Le superviseur logistique répartit entre l’agent de suivi et l’agent retours | Une demande tombe entre deux superviseurs et personne n’en est responsable | Y a-t-il un responsable unique pour chaque parcours, à chaque niveau ? |
| Transfert d’agent à agent | Chaque agent décide quand passer la conversation | L’agent Commandes transmet un cas d’article endommagé à l’agent Retours | Boucles (A vers B vers A), contexte perdu, client à qui l’on redemande deux fois les mêmes informations | Combien de transferts ? Un agent est-il apparu deux fois ? Le client a-t-il dû répéter une information ? |
| Transfert vers un humain | Un agent escalade vers une personne avec un résumé | L’agent Retours escalade un prélèvement contesté vers un conseiller | Escalade trop tardive, ou sans résumé, si bien que le conseiller repart de zéro | Bon déclencheur, bon moment, et le conseiller avait-il le contexte nécessaire ? |
| Rédacteur-vérificateur | Un agent rédige, un autre valide ou renvoie | Un agent rédige un geste commercial ; un vérificateur le contrôle par rapport aux règles | Le vérificateur laisse passer un mauvais brouillon, ou la boucle tourne jusqu’à une limite et envoie quand même la dernière version | Que fait le vérificateur quand il atteint le plafond d’itérations ? |
Les transferts d’agent à agent présentent le plus fort risque de boucles et de perte de contexte, et les transferts vers les humains sont l’endroit où les clients remarquent les défaillances en premier. Notre guide sur l’évaluation du transfert entre agent IA et conseiller approfondit cette ligne.
Où cassent les conversations de support multi-agents ?
Les conversations de support multi-agents cassent aux jonctions entre les agents, pas à l’intérieur. Les quatre défaillances qui comptent le plus sont le contexte perdu lors d’un transfert, les boucles entre agents, le mauvais agent qui agit sur une demande et la conversation clôturée avant que le problème soit résolu. Chacune peut survenir alors que chaque agent, pris isolément, semble correct.
Le contexte perdu. Les transferts transmettent moins que ce que la plupart des équipes supposent. Dans l’orchestration par transfert de Microsoft Agent Framework, les messages de l’utilisateur et des agents sont synchronisés entre les agents, mais le contenu lié aux outils n’est pas diffusé. L’agent suivant voit ce qui a été dit, pas forcément ce que l’agent précédent a consulté ou fait. Si l’agent Facturation ne voit pas la commande que l’agent Commandes a récupérée, il la redemande au client, ou travaille sur une supposition.
Les boucles. Deux agents peuvent se renvoyer une demande, ou un agent peut répéter la même étape. Le guide d’architecture de Microsoft cite les « boucles de transfert infinies » parmi les pièges du modèle par transfert et recommande des plafonds d’itérations pour les boucles. En mode autonome, son framework de transfert laisse chaque agent faire par défaut jusqu’à 50 tours avant de demander une intervention de l’utilisateur, bien plus que ce qu’un client tolérera.
Le mauvais agent qui agit. Une demande mal routée atteint un agent qui répond avec assurance hors de son domaine. La réponse est fluide, donc personne ne le remarque, sauf si quelqu’un la vérifie par rapport à la bonne règle.
La clôture prématurée. Les agents peuvent s’arrêter avant que le travail soit fait, ou ne pas savoir du tout quand ils ont terminé.
La recherche le confirme. Un article de 2025, Why Do Multi-Agent LLM Systems Fail? (en anglais), a annoté 1 642 traces d’exécution issues de sept frameworks et identifié 14 modes de défaillance. La répétition d’étapes apparaissait dans 15,7 % des traces, la non-reconnaissance de la fin de la tâche dans 12,4 % et la perte de contexte dans 2,8 %. Les auteurs ont aussi constaté que les exécutions réussies ne sont pas exemptes de défaillances. Les traces venaient de tâches de code, de mathématiques et de tâches générales, pas du service client : prenez ces parts comme un avertissement, pas comme un benchmark. La leçon, elle, se transpose : un résultat « résolu » peut cacher des défaillances en chemin, comme le montre notre article sur les erreurs silencieuses des agents IA.
Que surveiller dans une organisation de support orchestrée ?
Surveillez le parcours, pas seulement chaque agent. Les notes par agent montrent si l’agent Facturation répond bien aux questions de facturation, pas si les clients ont rebondi entre trois agents avant de l’atteindre. Suivez plutôt un petit ensemble de signaux de parcours : transferts, boucles, informations demandées deux fois au client, justesse du premier routage, escalades avec contexte et écart entre résolution par agent et résolution du parcours.
Les règles de départ ci-dessous sont les nôtres, pas une norme du secteur : mesurez votre propre niveau de référence pendant quatre semaines, puis ajustez.
| Signal | Comment le mesurer | Règle de départ |
|---|---|---|
| Transferts par conversation | Compter les changements d’agent dans le journal de la conversation | Relire chaque conversation avec plus de 3 transferts |
| Agent répété (boucle) | Le même agent apparaît deux fois dans une conversation, avec un autre agent entre les deux | Les relire toutes ; toute tendance à la hausse est un bug de routage |
| Taux de redemande | Le client donne deux fois le même identifiant (numéro de commande, e-mail) | Analyser au-delà de 5 % des conversations multi-agents |
| Justesse du premier routage | Part des premiers routages jugés corrects par un évaluateur | Analyser le routeur en dessous de 90 % |
| Escalade avec contexte | Part des transferts vers un humain où le conseiller n’a pas eu à redemander | Viser 95 % ou plus |
| Écart de résolution | Taux « résolu » par agent moins taux de parcours résolus correctement | Un écart de plus de 5 points signifie que des défaillances se cachent entre les agents |
| Limite de tours ou d’itérations atteinte | Conversations terminées parce qu’une limite a été atteinte | Les relire toutes ; ce sont des boucles bloquées |
Les recommandations de Microsoft disent la même chose du côté de l’ingénierie : instrumenter toutes les opérations des agents et tous les transferts, et utiliser des grilles d’évaluation ou une évaluation par modèle juge plutôt que des tests de correspondance exacte, car les réponses des agents varient. Pour les tableaux de bord et les alertes, consultez notre guide sur le monitoring des agents IA.
Comment contrôler la qualité d’un parcours qui traverse plusieurs agents et humains ?
Pour contrôler la qualité d’un parcours multi-agents, faites de la conversation complète l’unité de relecture. Rassemblez chaque segment, agent ou humain, dans un seul enregistrement, évaluez chaque segment par rapport à sa mission, évaluez les jonctions avec des critères de parcours et attribuez chaque défaillance au segment qui l’a causée. Corrigez ensuite cette partie et réévaluez.
Étape 1 : reconstituer le parcours. Un seul identifiant de conversation suit le client à travers chaque agent et chaque humain. Si vos agents enregistrent à des endroits différents, la première tâche du contrôle qualité est d’obtenir la transcription complète, avec le nom de l’agent à chaque tour, dans le helpdesk ou dans une seule file de relecture.
Étape 2 : évaluer chaque segment par rapport à sa mission. L’exactitude de la facturation pour l’agent Facturation, le routage pour l’agent de tri, la résolution pour le conseiller. Un socle commun de critères garde les segments humains et IA comparables ; notre guide sur une grille d’évaluation commune aux conseillers et aux agents IA montre comment la construire.
Étape 3 : ajouter des critères de parcours. Ce sont les questions auxquelles aucun segment ne peut répondre seul :
- Le premier routage était-il juste ?
- Le client a-t-il dû répéter une information ?
- Un agent est-il apparu deux fois, ou la conversation a-t-elle tourné en boucle ?
- Chaque transfert a-t-il transmis les données dont l’agent suivant avait besoin ?
- Si un humain a pris le relais, l’escalade s’est-elle faite sur le bon déclencheur, avec un résumé utilisable ?
- Le vrai problème du client était-il résolu à la fin, quel que soit celui qui l’a résolu ?
Étape 4 : attribuer la défaillance. Chaque parcours en échec reçoit un seul segment à l’origine : le routeur, un spécialiste, le mécanisme de transfert ou le conseiller. Sans attribution, une défaillance de parcours est le problème de tout le monde et la correction de personne.
Étape 5 : corriger et réévaluer. Transmettez le constat au responsable de cette partie (prompt, règle de routage, article de connaissances, déclencheur d’escalade), puis réévaluez le même type de parcours pour confirmer que la correction tient. Testez les modifications avant leur mise en ligne ; consultez notre guide sur les tests d’agents IA.
Un exemple chiffré (illustration, chiffres inventés pour montrer le calcul)
Une équipe support traite 40 000 conversations par mois avec un agent de tri, trois agents spécialisés et une équipe de conseillers :
- 26 000 conversations (65 %) passent du tri à un seul spécialiste et s’y terminent.
- 10 000 (25 %) passent par deux agents IA ou plus.
- 4 000 (10 %) se terminent avec un conseiller.
Les tableaux de bord par agent semblent sains : chaque spécialiste réussit plus de 90 % de ses propres critères. Le responsable qualité évalue alors un échantillon aléatoire de 200 parcours multi-agents avec les critères de parcours ci-dessus. 34 échouent (17 %) : 14 clients ont dû redonner leur numéro de commande, 9 conversations sont revenues au tri, 6 ont été traitées par le mauvais spécialiste et 5 ont été clôturées avant la confirmation du remboursement.
À l’échelle, 17 % de 10 000 représentent environ 1 700 parcours en échec par mois. Si les parcours à un seul agent échouent à 5 %, cela fait 1 300 échecs sur 26 000. Le quart des conversations qui traversent plusieurs agents produit plus d’échecs que les deux tiers qui n’en traversent qu’un.
L’échantillon montre aussi les limites de l’échantillonnage. Avec 200 conversations et un taux d’échec de 17 %, la marge d’erreur à 95 % est d’environ plus ou moins 5,2 points (1,96 × √(0,17 × 0,83 / 200)). L’intervalle à 95 % va d’environ 1 200 à 2 200 parcours en échec. Et les 14 redemandes pointent vers une seule correction : le résultat de la recherche de l’agent Commandes n’atteint pas l’agent Facturation lors du transfert.
Voyez-le sur vos propres conversations. Kaizo évalue 100 % de vos conversations de support, celles des conseillers comme celles des agents IA, selon votre propre grille, et relie chaque note aux preuves dans la conversation. Réserver une démo.
Quel framework ou quelle plateforme d’orchestration des agents IA choisir ?
Le meilleur framework d’orchestration des agents IA est celui que votre fournisseur d’agents ou votre équipe d’ingénierie maîtrise déjà ; les responsables support le choisissent rarement seuls. Ce que vous devez fixer, ce sont les exigences : un routage visible par conversation, un contexte transmis lors des transferts, des limites de tours, une escalade vers un humain avec résumé, et des transcriptions qui arrivent là où travaille votre équipe qualité.
Les options se répartissent en trois groupes :
- Intégrée à votre plateforme d’agents IA. Les plateformes d’agents pour le service client routent entre leurs propres agents et vers votre équipe humaine. Le moins de travail, le moins de contrôle.
- Frameworks pour développeurs. Microsoft Agent Framework, le SDK OpenAI Agents, LangChain et CrewAI, entre autres. Un contrôle total, et vos ingénieurs sont responsables de chaque règle.
- Couches d’orchestration d’entreprise. Des produits comme IBM watsonx Orchestrate coordonnent agents, outils et workflows depuis une couche centrale, pour toute l’entreprise.
Quel que soit votre groupe, posez cinq questions avant la mise en service :
- Pouvons-nous voir, pour chaque conversation, quel agent a agi à chaque tour et pourquoi il a transféré ?
- Qu’est-ce qui est transmis exactement lors d’un transfert : la transcription, un résumé, les résultats des outils, les données client ?
- Quelles sont les limites de tours et d’itérations, et que se passe-t-il quand l’une est atteinte ?
- Comment un humain prend-il le relais, et que voit-il en premier ?
- Où arrive la transcription complète, et notre équipe qualité peut-elle l’évaluer à cet endroit ?
Si la réponse est « nous ne pouvons pas vous le montrer », vous ne pourrez pas non plus contrôler le parcours.
Quand l’orchestration multi-agents n’est-elle pas pour vous ?
L’orchestration multi-agents n’est pas pour vous quand un seul agent IA bien délimité, avec les bons outils et un chemin d’escalade clair, peut absorber votre volume. Les recommandations de Microsoft conseillent d’utiliser le niveau de complexité le plus bas qui réponde de façon fiable à vos besoins, et qualifient un agent unique doté d’outils de choix par défaut souvent pertinent pour les cas d’usage en entreprise. Chaque agent supplémentaire ajoute des transferts, de la latence, des coûts et des modes de défaillance.
Les praticiens des forums de customer success font un constat proche : les gains viennent en général d’un agent IA qui traite bien un ensemble restreint de questions, pas d’un agent qui essaie de tout couvrir. Si votre agent IA traite quelques centaines de conversations par mois dans un seul domaine, laissez de côté l’orchestration, lisez les transcriptions chaque semaine et consacrez l’effort à la base de connaissances et au déclencheur d’escalade.
Le routage lui-même vient de votre plateforme d’agents ou de l’un des frameworks ci-dessus. Le rôle de Kaizo commence après la conversation : il évalue les conversations résolues dans Zendesk ou Salesforce selon votre grille.
Par où commencer cette semaine
Vous pouvez commencer à relire des parcours orchestrés cette semaine sans nouvel outil : dessinez la façon dont vos agents sont reliés, puis évaluez un petit ensemble de parcours multi-agents avec les critères de parcours. L’objectif de la première semaine n’est pas un tableau de bord ; c’est de trouver la jonction qui échoue le plus.
- Dessinez vos connexions. Listez chaque agent IA, qui peut transférer à qui, et où interviennent les humains, avec le modèle correspondant du tableau ci-dessus.
- Extrayez 30 parcours multi-agents, plus 10 qui se sont terminés avec un conseiller.
- Évaluez-les avec les six critères de parcours, en notant le segment à l’origine de chaque défaillance.
- Choisissez la pire jonction. En général, un transfert qui perd le contexte ou une règle de routage qui se trompe.
- Nommez un responsable pour chaque agent et chaque règle de transfert.
Quand la relecture manuelle a confirmé le schéma, automatisez-la. Le contrôle qualité des agents IA de Kaizo évalue les conversations des agents IA avec la même grille que celle de votre équipe, y compris des critères de transfert comme l’escalade sur le bon déclencheur et la transmission du contexte, et AutoPilot évalue chaque conversation dès qu’elle est résolue. Pour la vue d’ensemble, commencez par notre guide sur le service client agentique ; pour les règles que suivent ces agents, consultez la gouvernance des agents IA.
Questions fréquentes
ChatGPT est-il un agent ou un LLM ?
ChatGPT est un produit construit sur des grands modèles de langage (LLM). Quand il répond à une seule question, il se comporte comme une interface de chat vers un LLM. Quand il utilise des outils, navigue sur le web ou mène seul une tâche en plusieurs étapes, il se comporte comme un agent. La différence tient à ce que le système a le droit de faire, pas au modèle.
Quelle est la différence entre un système multi-agents et l’IA agentique ?
L’IA agentique désigne une IA qui agit vers un objectif avec une certaine autonomie. Un système multi-agents est une façon de la construire : plusieurs agents spécialisés, coordonnés par une orchestration, au lieu d’un seul agent qui fait tout. Un agent unique peut être agentique ; un système multi-agents ajoute les transferts, et avec eux les jonctions à vérifier.
Kubernetes est-il un outil d’orchestration ?
Oui, mais pour les conteneurs, pas pour les agents IA. Kubernetes planifie et dimensionne les logiciels qui font tourner vos services. L’orchestration des agents IA décide quel agent traite quelle partie d’une conversation et quel contexte il reçoit. Un système d’agents peut tourner sur Kubernetes, mais Kubernetes ne route pas les demandes entre les agents.
Qu’est-ce qu’une couche d’orchestration d’agents IA ?
La couche d’orchestration se situe au-dessus des agents individuels et décide du routage, de la transmission du contexte, des autorisations et des règles d’arrêt. Il peut s’agir d’un agent principal, d’un framework dans votre propre code ou d’un produit central. Pour le contrôle qualité, elle doit aussi fournir l’historique de qui a agi et pourquoi.
Comment évaluer un système de service client multi-agents ?
Évaluez-le à deux niveaux : chaque agent par rapport à sa propre mission, et le parcours complet selon des critères comme un premier routage juste, aucune information redemandée, aucune boucle et un résultat final correct. Notre guide sur l’évaluation des agents IA présente les méthodes, des jeux de tests à l’évaluation des conversations en production.
