>Orchestration multi-agents dans Copilot Studio : design patterns pour PME

Le pattern de base : un orchestrateur, des spécialistes

Le design pattern le plus utile pour une PME, c'est l'agent orchestrateur qui reçoit la demande de l'utilisateur, comprend l'intention, puis délègue à un agent spécialiste. Concrètement, on parle ici d'un agent d'accueil qui couvre tous les départements, et qui appelle un agent RH, un agent Ventes ou un agent Support selon ce que l'employé demande.

Imaginez une PME de 80 personnes : un employé écrit « il me reste combien de jours de vacances et est-ce que je peux les prendre la semaine du 5 mai? ». L'orchestrateur reconnaît qu'on parle de RH, transmet la conversation à l'agent RH, lequel interroge le SIRH, applique les politiques internes et répond. L'utilisateur, lui, n'a parlé qu'à un seul interlocuteur. C'est cette transparence qui rend l'expérience fluide.

Quand chaîner, quand fusionner

Une question qu'on se pose vite : faut-il vraiment plusieurs agents, ou un seul agent avec plusieurs sujets ferait l'affaire? Voici les balises qu'on peut retenir.

On chaîne (donc plusieurs agents connectés) quand les domaines sont gouvernés par des équipes différentes, quand les sources de données sont segmentées (Dataverse RH versus CRM Ventes), ou quand on veut qu'un département puisse faire évoluer son agent sans casser celui des autres. C'est aussi la bonne approche si on veut publier certains agents dans des canaux différents (un agent Support exposé sur le site web public, un agent RH uniquement dans Teams interne).

On fusionne quand les sujets se chevauchent fortement, quand les sources de données sont les mêmes, ou quand le volume de questions est trop bas pour justifier un agent dédié. Multiplier les agents juste « parce qu'on peut », c'est se créer une dette technique inutile.

Frontières d'autonomie et délégation

Le vrai défi de l'orchestration, ce n'est pas de connecter les agents entre eux : c'est de définir jusqu'où chacun peut aller seul. Pour une PME, on recommande trois cercles d'autonomie.

Le premier cercle, c'est la lecture seule : l'agent peut chercher, résumer, comparer, sans toucher aux systèmes. C'est le territoire par défaut, le moins risqué. Le deuxième cercle, c'est la transaction encadrée : l'agent peut créer un ticket, soumettre une demande de congé, mettre à jour une fiche client, mais à l'intérieur de règles précises (montants, statuts, types de demandes). Le troisième cercle, c'est l'action sensible : approbations, accès à des données confidentielles, communications externes. Là, on garde un humain dans la boucle, point.

Quand un agent spécialiste doit franchir un cercle, il remonte la main à l'orchestrateur, qui peut soit demander une confirmation à l'utilisateur, soit déclencher une approbation Power Automate. C'est un design pattern de « handback » qui évite que l'agent prenne des décisions au-dessus de son mandat.

Supervision et gouvernance

Un système multi-agents sans supervision, c'est une boîte noire. Les outils de gouvernance agentique introduits dans Copilot Studio permettent de suivre qui appelle qui, combien de fois, et à quel coût. Pour une PME, trois éléments à mettre en place dès le départ : une convention de nommage claire (préfixe par département), un environnement Dataverse dédié aux agents de production, et un tableau de bord d'utilisation pour repérer les boucles, les délégations qui échouent ou les agents sous-utilisés.

On ajoute aussi une règle simple : un nouvel agent ne passe en production qu'avec un parrain métier identifié. Pas de parrain, pas de mise en ligne. Ça évite la prolifération d'agents orphelins que personne ne maintient six mois plus tard.

Mon avis

L'orchestration multi-agents, c'est ce qui sépare un POC sympathique d'une vraie plateforme conversationnelle d'entreprise. Pour les PME, la tentation sera de viser trop gros tout de suite. À mon sens, le bon réflexe est de commencer petit : un orchestrateur, deux spécialistes (souvent RH et Support, parce que le ROI est évident), des frontières d'autonomie strictes, et de la supervision dès le jour un. On élargit ensuite quand on a des données d'usage, pas avant.

Le tutoriel de Matthew Devaney est un excellent point de départ pour visualiser concrètement comment se configurent les connected agents. Combiné aux contrôles de gouvernance déjà disponibles dans Copilot Studio, on a maintenant tout ce qu'il faut pour bâtir des solutions sérieuses, sans tomber dans l'usine à gaz.

Je suis Éric Sauvé MCT & MVP, aka ZePowerDiver, Directeur IA & Power Platform chez Solulan. J'adore la Power Platform, l'automatisation, l'optimisation des processus et l'application de l'intelligence artificielle en ces domaines.

Vous pouvez me retrouver:

LinkedIn: https://www.linkedin.com/in/zepowerdiver
Twitter: https://twitter.com/ZePowerDiver
YouTube: https://www.youtube.com/c/ZePowerDiver
Blogger: https://www.zepowerdiver.com/
Github: https://github.com/ZePowerdiver/

Sources : Matthew Devaney (MVP), « Master Multi-Agent Orchestration In Copilot Studio », matthewdevaney.com; documentation Microsoft Copilot Studio sur les connected agents et la gouvernance agentique, Microsoft Learn.