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.

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.
| Agent | Responsabilité |
| Loan Application Reviewer | Reçoit la demande et coordonne le workflow |
| Agent d’extraction | Lit le PDF et récupère les champs sans interpréter |
| Couche de règles | Valide la cohérence avec des critères explicites |
| Agent de connaissance | Enrichit la décision avec les documents SharePoint |
| Agent de rédaction | Pré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.

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ément | Rôle | Risque si mal préparé |
| Bibliothèque Loan Applications | Centraliser les demandes de prêt | Déclencheurs confus ou workflow branché au mauvais endroit |
| PDF de demande | Fournir les données à extraire | Données absentes, mal lues ou impossibles à exploiter |
| Droits d’accès | Autoriser Copilot Studio ou le connecteur à lire le fichier | Erreur 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.

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.
| Étape | Entrée | Sortie |
| Déclencheur SharePoint | Nouveau fichier dans Loan Applications | Nom, ID, chemin, propriétés du fichier |
| Récupération des métadonnées | Identifiant du fichier | Contexte SharePoint propre |
| Récupération du contenu | ID ou chemin du fichier | Contenu binaire du PDF |
| Transmission à l’agent suivant | PDF + métadonnées utiles | Document 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.

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.
| applicantName | Nom du demandeur tel qu’il apparaît dans le PDF |
| applicantId | Identifiant du demandeur, s’il est présent |
| employmentStatus | Statut d’emploi exact indiqué dans le document |
| annualIncome | Revenu annuel avec le libellé ou le format d’origine |
| requestedLoanAmount | Montant demandé tel qu’affiché |
| Email présent dans le document | |
| missingFields | Liste 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.

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 validationErrorsLe 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.
| Composant | Responsabilité | Pourquoi c’est utile |
| Règles codées | Valider les données et produire la décision | On garde le contrôle métier |
| Agent SharePoint | Consulter les politiques internes | On évite les réponses inventées |
| Agent e-mail | Rédiger un message compréhensible | On 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.
⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.




