Comment créer un workflow multi-agents Copilot Studio ?

On crée un workflow multi-agents Copilot Studio en séparant extraction, validation, connaissance et réponse. Le vrai sujet, c’est de rendre le traitement plus fiable qu’un gros prompt unique. Je vous montre le cas concret d’une demande de prêt PDF dans SharePoint.


Besoin d'aide ? Découvrez les solutions de notre agence d'agents IA.



Pourquoi utiliser plusieurs agents ?



Plusieurs agents servent à découper un traitement complexe en petites responsabilités plus contrôlables. Dans Copilot Studio, l’idée n’est pas de créer une usine à gaz avec des agents partout. L’idée, c’est de séparer ce qui doit être séparé, surtout quand on traite un dossier sensible comme une demande de prêt en PDF stockée dans SharePoint.

Comment créer un workflow multi-agents Copilot Studio ?

Je le vois comme une chaîne de travail. Un agent principal, par exemple Loan Application Reviewer, reçoit la demande. Il orchestre le workflow, mais il ne fait pas tout lui-même. Un agent spécialisé extrait les champs du PDF tels quels : nom, revenus, montant demandé, durée, garanties, pièces jointes. Une couche de règles vérifie ensuite la cohérence. Par exemple, est-ce que le revenu mensuel correspond aux justificatifs ? Est-ce que le montant demandé respecte les critères internes ? Est-ce que des champs obligatoires manquent ?

Ensuite, un agent de connaissance peut aller chercher du contexte dans SharePoint, comme une politique de crédit, une grille de risque ou une procédure interne. Puis un autre agent rédige un e-mail clair au demandeur, avec les pièces manquantes ou la suite du process. Chacun fait son job. Et ça change beaucoup de choses.

AgentResponsabilité
Loan Application ReviewerReçoit la demande et coordonne le workflow
Agent d’extractionLit le PDF et récupère les champs sans interpréter
Couche de règlesValide la cohérence avec des critères explicites
Agent de connaissanceEnrichit la décision avec les documents SharePoint
Agent de rédactionPrépare un e-mail propre pour le demandeur

Le vrai gain, ce n’est pas de faire joli. C’est de gagner en qualité, en prévisibilité, et parfois en vitesse quand certaines tâches peuvent tourner en parallèle. L’extraction du PDF peut se faire pendant qu’un autre agent charge les règles applicables, par exemple.

Honnêtement, quand je vois des automatisations IA qui tiennent mal dans le temps, c’est souvent parce qu’on a demandé à un seul agent de lire, interpréter, décider et rédiger en même temps. Au début ça marche. Puis les exceptions arrivent, les documents changent, les règles évoluent, et l’agent commence à mélanger les rôles.

Avant de parler IA, il faut donc poser une base simple : une source de fichiers propre dans SharePoint. Si les PDF sont mal rangés, mal nommés ou difficiles à retrouver, le workflow multi-agents part déjà avec un handicap.



Comment préparer SharePoint ?



Il faut créer une bibliothèque SharePoint dédiée aux demandes de prêt et y déposer les PDF à traiter.

Comment créer un workflow multi-agents Copilot Studio ?

Je crée généralement une bibliothèque nommée Loan Applications dans le site SharePoint utilisé par l’équipe métier. Pas un dossier caché dans “Documents partagés”, pas un sous-répertoire oublié entre deux exports Excel. Une vraie bibliothèque, avec son nom, ses droits, son historique, et un usage clair.

Dedans, je dépose un premier fichier de test, par exemple Priya Kapoor – Loan Application.pdf. Ce PDF contient la demande de prêt de Priya Kapoor, avec les informations que le workflow devra lire ensuite : identité, montant demandé, revenus, situation professionnelle, durée du prêt, pièces justificatives si besoin. C’est bête, mais je préfère toujours partir d’un cas concret. Un client m’avait donné trois faux PDF “propres”, puis les vrais documents étaient scannés de travers avec des champs manquants. Le workflow marchait en démo, beaucoup moins en production.

Je préfère une bibliothèque dédiée pour quatre raisons simples :

  • Le déclencheur est plus clair. Quand un fichier arrive dans Loan Applications, je sais que c’est une demande de prêt à traiter.
  • Les droits sont plus simples. Je peux donner accès uniquement au compte utilisé par Copilot Studio ou par le connecteur SharePoint.
  • Les tests sont plus propres. Je peux déposer, supprimer, renommer des fichiers sans toucher aux autres documents du site.
  • Il y a moins de faux positifs. Le workflow ne part pas sur un PDF RH, une facture fournisseur ou un document commercial.

Avant d’automatiser, je vérifie quelques points. Le PDF doit être accessible par le compte utilisé dans Copilot Studio ou dans le connecteur SharePoint. Le fichier doit vraiment contenir les informations à extraire, pas juste une image illisible sans OCR, l’OCR étant la reconnaissance automatique du texte dans une image. La bibliothèque doit aussi rester stable. Si quelqu’un la renomme ou change son URL, le workflow peut casser.

ÉlémentRôleRisque si mal préparé
Bibliothèque Loan ApplicationsCentraliser les demandes de prêtDéclencheurs confus ou workflow branché au mauvais endroit
PDF de demandeFournir les données à extraireDonnées absentes, mal lues ou impossibles à exploiter
Droits d’accèsAutoriser Copilot Studio ou le connecteur à lire le fichierErreur d’accès, extraction bloquée, automatisation inutile

Cette bibliothèque devient le point d’entrée du workflow. Dès qu’un PDF y arrive, le reste de l’automatisation peut démarrer proprement.



Comment déclencher le workflow ?



Le workflow démarre avec le déclencheur SharePoint When a File Is Created (Properties Only), puis il récupère le contenu du fichier avant de l’envoyer au prochain agent.

Comment créer un workflow multi-agents Copilot Studio ?

Dans Copilot Studio, je crée le workflow comme une action automatisée, souvent via un flux cloud Power Automate associé au copilote. Je choisis le déclencheur SharePoint, puis je sélectionne le site où les dossiers arrivent. Dans mon cas, la bibliothèque s’appelle Loan Applications. C’est là que les PDF de demande de prêt sont déposés.

Le point important, c’est le “Properties Only”. Ce déclencheur ne lit pas vraiment le PDF. Il récupère surtout les métadonnées du fichier : son nom, son identifiant, son chemin, sa date de création, parfois l’utilisateur qui l’a ajouté. C’est utile, mais ce n’est pas encore le contenu exploitable par un agent IA.

Donc juste après le déclencheur, j’ajoute une action SharePoint du type Get file content ou Get file content using path. Cette action va chercher les octets du fichier, donc le vrai contenu à transmettre ensuite à l’étape d’analyse. Sans ça, l’agent risque de recevoir une référence de fichier au lieu du document lui-même. Et là, il peut quand même répondre, mais sur du vide. C’est le genre de bug qui a l’air intelligent et qui fait perdre du temps.

La logique du flux reste simple :

  • Le déclencheur détecte qu’un nouveau PDF arrive dans SharePoint.
  • Les métadonnées permettent d’identifier le bon fichier.
  • Le contenu est récupéré explicitement avec une action dédiée.
  • Le prochain agent reçoit un fichier exploitable, pas juste une propriété SharePoint.
ÉtapeEntréeSortie
Déclencheur SharePointNouveau fichier dans Loan ApplicationsNom, ID, chemin, propriétés du fichier
Récupération des métadonnéesIdentifiant du fichierContexte SharePoint propre
Récupération du contenuID ou chemin du fichierContenu binaire du PDF
Transmission à l’agent suivantPDF + métadonnées utilesDocument prêt pour analyse IA

Je teste toujours cette partie avant d’appeler l’IA. Je vérifie que le fichier récupéré est le bon, que le contenu n’est pas vide, et que le nom correspond bien au dossier attendu. Un agent qui reçoit un mauvais fichier donnera une mauvaise réponse avec beaucoup d’assurance. J’ai vu ça chez un client sur des justificatifs inversés entre deux dossiers, et franchement, le workflow avait l’air propre jusqu’au moment où on a testé les fichiers un par un.



Comment extraire les champs du PDF ?



Il faut confier l’extraction à un agent spécialisé qui lit le PDF et renvoie les champs sans reformulation.

Comment créer un workflow multi-agents Copilot Studio ?

Dans Copilot Studio, je crée donc un agent séparé, uniquement dédié à cette tâche. Son rôle est simple : lire le document, extraire les valeurs telles qu’elles apparaissent, et retourner une sortie structurée. Pas de correction automatique. Pas de supposition. Pas de “ça doit sûrement vouloir dire…”. Si le PDF indique “CDD”, l’agent retourne “CDD”. Si le montant est écrit “45 000 €”, il retourne “45 000 €”, pas “45000” sauf si vous lui demandez explicitement de normaliser plus tard.

Cette séparation est importante parce que les règles de validation vont s’appuyer sur cette sortie. Si l’extraction est floue, tout le reste devient fragile. J’ai déjà vu des workflows bloqués pendant des heures alors que les règles étaient bonnes. Le vrai souci venait juste d’un agent qui “améliorait” les données au lieu de les extraire.

applicantNameNom du demandeur tel qu’il apparaît dans le PDF
applicantIdIdentifiant du demandeur, s’il est présent
employmentStatusStatut d’emploi exact indiqué dans le document
annualIncomeRevenu annuel avec le libellé ou le format d’origine
requestedLoanAmountMontant demandé tel qu’affiché
emailEmail présent dans le document
missingFieldsListe des champs attendus mais absents du PDF

Dans les consignes de l’agent, je mets quelque chose de très explicite, parce que c’est là que tout se joue :

Extrais uniquement les informations présentes dans le PDF.
Ne devine jamais une valeur absente.
Ne corrige pas les noms, montants, statuts ou identifiants.
Conserve les libellés et les montants tels qu’ils apparaissent dans le document.
Retourne toujours la même structure avec les champs suivants :
applicantName, applicantId, employmentStatus, annualIncome, requestedLoanAmount, email, missingFields.
Si une information est absente, laisse le champ vide et ajoute son nom dans missingFields.

Ensuite, je publie le workflow, je dépose ou redépose le PDF, puis je relance un test complet. Je vérifie champ par champ que les valeurs extraites correspondent au document, pas à ce que l’agent pense avoir compris.

Cette phase paraît lente, je sais. Mais elle évite de débugger des règles de validation pendant une heure alors que le problème vient juste de l’extraction. C’est un petit coût au départ, et souvent un gros gain derrière.



Comment valider et répondre ?



La décision doit être pilotée par des règles explicites avant de demander à l’IA de rédiger l’e-mail. Sinon on laisse l’agent “deviner” une décision métier, et franchement, c’est le meilleur moyen de créer un workflow joli mais dangereux.

Comment créer un workflow multi-agents Copilot Studio ?

Dans le workflow, je commence par initialiser une variable tableau qui contient les règles de validation. Ensuite, j’évalue les champs extraits du formulaire ou du document : ID demandeur, statut d’emploi, revenu annuel, montant du prêt demandé. L’IA peut aider à extraire ou reformuler, mais la validation doit rester codée en dur.

<!-- Exemple de structure de règles documentée dans le workflow -->
{
  "rules": [
    {
      "id": "REQ_APPLICANT_ID",
      "label": "ID demandeur obligatoire",
      "severity": "blocking",
      "condition": "isEmpty(applicantId)",
      "message": "L’identifiant du demandeur est manquant."
    },
    {
      "id": "EMPLOYMENT_CONFLICT",
      "label": "Statut d’emploi incohérent",
      "severity": "blocking",
      "condition": "employmentStatus contains employed and unemployed",
      "message": "Le demandeur ne peut pas être Employé et Chômeur en même temps."
    },
    {
      "id": "INVALID_INCOME",
      "label": "Revenu annuel invalide",
      "severity": "blocking",
      "condition": "annualIncome <= 0",
      "message": "Le revenu annuel doit être présent et supérieur à zéro."
    }
  ]
}

Dans Power Automate, la logique reste très lisible. J’aime bien faire simple ici, parce que ce sont des règles qu’un métier doit pouvoir relire sans appeler un développeur à chaque fois.

Initialiser validationErrors = []

Si applicantId est vide
  Ajouter "ID demandeur manquant" dans validationErrors

Si employmentStatus contient "employed" et "unemployed"
  Ajouter "Statut d’emploi incohérent" dans validationErrors

Si annualIncome est vide ou annualIncome <= 0
  Ajouter "Revenu annuel invalide" dans validationErrors

Si requestedLoanAmount > annualIncome * ratioAutorise
  Ajouter "Montant demandé trop élevé par rapport au revenu" dans validationErrors

Le ratio autorisé ne doit pas sortir de la tête de l’agent. Il doit venir de la politique interne de l’entreprise, par exemple une règle de risque validée par les équipes crédit.

On peut ensuite ajouter un agent de connaissance connecté à SharePoint pour consulter les règles internes de prêt. Il ne décide pas seul, il récupère le contexte fiable. Puis un agent de rédaction transforme la décision en e-mail clair pour le demandeur : accepté, refusé, ou demande d’informations complémentaires. À la fin, le workflow envoie l’e-mail au demandeur.

ComposantResponsabilitéPourquoi c’est utile
Règles codéesValider les données et produire la décisionOn garde le contrôle métier
Agent SharePointConsulter les politiques internesOn évite les réponses inventées
Agent e-mailRédiger un message compréhensibleOn gagne du temps sans perdre en clarté


Et si votre agent devenait enfin fiable ?



Un bon workflow multi-agents Copilot Studio ne commence pas par un prompt magique. Il commence par une source propre dans SharePoint, un déclencheur fiable, une extraction PDF sans interprétation, puis des règles de validation explicites. L’IA arrive ensuite là où elle est forte : aider à lire, structurer, enrichir avec de la connaissance et rédiger une réponse claire. C’est cette séparation qui rend le système plus testable et moins fragile. Pour vous, le bénéfice est simple : vous automatisez un vrai processus business sans perdre le contrôle sur la décision.



FAQ



  • Qu’est-ce qu’un workflow multi-agents dans Copilot Studio ?
    C’est une automatisation où plusieurs agents ont chacun un rôle précis. Dans l’exemple d’une demande de prêt, un agent extrait les champs du PDF, une couche de règles valide les données, un autre agent peut consulter des documents SharePoint, puis un agent rédige l’e-mail de réponse.
  • Pourquoi ne pas utiliser un seul agent pour tout faire ?
    Un seul agent peut marcher sur une démo, mais il devient vite moins prévisible. En séparant extraction, validation et rédaction, on teste chaque bloc plus facilement et on réduit les erreurs silencieuses. C’est beaucoup plus sain pour un process business.
  • Quel déclencheur SharePoint faut-il utiliser ?
    Le déclencheur utilisé est When a File Is Created (Properties Only). Il permet de lancer le workflow quand un fichier arrive dans la bibliothèque SharePoint. Ensuite, il faut récupérer le contenu du fichier pour que l’agent puisse réellement lire le PDF.
  • Comment éviter que l’agent invente des données du PDF ?
    Je lui donne une consigne stricte : extraire les champs tels quels, sans reformulation, sans correction et sans déduction. Les champs absents doivent rester absents ou être signalés comme manquants. La sortie doit être structurée pour pouvoir être validée ensuite.
  • Les règles de décision doivent-elles être gérées par l’IA ?
    Pas seules. Les règles critiques doivent être explicites dans le workflow, par exemple vérifier l’ID demandeur, le statut employé ou chômeur, le revenu annuel et le montant demandé. L’IA peut aider à exploiter la connaissance et à rédiger, mais la décision doit rester contrôlable.

 

 

A propos de l’auteur



Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et mon organisme Formations Analytics, j’accompagne des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets data, IA et automatisation très concrets. Si vous voulez mettre en place des workflows IA fiables dans votre business, vous pouvez me contacter.

Retour en haut
Le Web Analyste