Un workflow multi-agent Copilot Studio se construit en découpant le traitement en agents spécialisés. Je prends ici un cas concret de demande de prêt PDF, avec extraction, validation, enrichissement SharePoint, décision et email final. C’est plus propre, plus rapide, et surtout plus contrôlable.
Pourquoi découper le workflow en agents ?
Quand je découpe un workflow en agents dans Copilot Studio, ce n’est pas pour faire plus “agentique” ou plus moderne. C’est surtout pour éviter le gros agent fourre-tout qui lit un document, comprend le contexte, applique des règles, prend une décision, rédige un email… et devient impossible à suivre dès qu’un détail part de travers.
Dans le cas Loan Application Reviewer, le scénario est assez simple. Un fichier PDF de demande de prêt arrive dans SharePoint. Le workflow se déclenche, récupère le document, puis passe le contenu à un agent spécialisé dans l’extraction. Cet agent ne décide rien. Il sort juste des champs propres, par exemple le nom du demandeur, le montant demandé, les revenus, la durée du prêt, les pièces jointes présentes ou manquantes.
Comment créer un AI Data Analyst fiable en Python ?
Ensuite, une étape applique les règles de validation. Là, on sort du flou. Une règle, c’est quelque chose qu’on peut relire et tester. Si le montant dépasse un seuil, si un justificatif manque, si le ratio dette / revenu est trop élevé, on le sait précisément. Un autre agent peut interroger la connaissance SharePoint pour vérifier certaines informations, par exemple une politique interne, une grille d’éligibilité ou une procédure à jour. Le dernier agent rédige l’email de réponse avec la décision et les raisons principales, puis le demandeur reçoit une réponse claire.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
J’ai souvent vu chez des clients des automatisations IA trop ambitieuses dès le départ. Un prompt géant qui mélange extraction, décision et rédaction. Sur le papier ça marche. En démo aussi. Puis en production, quand une demande est mal classée ou qu’un email dit n’importe quoi, on ne sait plus où ça casse. Est-ce que le PDF a été mal lu ? Est-ce que la règle était ambiguë ? Est-ce que le modèle a improvisé ? Personne ne sait vraiment.
Avec plusieurs agents, chaque bloc a une mission courte, une entrée claire et une sortie attendue. C’est plus fiable, plus testable, et surtout plus maintenable. L’objectif n’est pas de faire joli avec de l’IA. L’objectif, c’est de rendre un processus business exécutable, auditable et contrôlable.
| Agent ou étape | Rôle | Entrée | Sortie attendue |
| Déclencheur SharePoint | Détecter une nouvelle demande | PDF ajouté dans une bibliothèque SharePoint | Document récupéré et transmis au workflow |
| Agent d’extraction | Lire le PDF et extraire les champs utiles | Contenu du document | Données structurées de la demande |
| Étape de validation | Appliquer les règles métier | Données extraites | Décision provisoire et raisons |
| Agent de connaissance SharePoint | Vérifier ou enrichir avec les documents internes | Données de la demande et contexte métier | Informations complémentaires fiables |
| Agent de rédaction | Préparer la réponse au demandeur | Décision, raisons, contexte | Email clair prêt à envoyer |
Comment préparer SharePoint ?
Comment utiliser le reflection pattern en production ?
Je prépare SharePoint comme un sas d’entrée propre. L’idée est simple : tous les PDF de demande de prêt arrivent au même endroit, et Copilot Studio sait exactement où écouter. Ça évite les déclencheurs flous, les fichiers perdus dans un dossier partagé, et les “attends, il était où le document déjà ?”.
Dans SharePoint, je crée une bibliothèque de documents que j’appelle Loan Applications. Pas un dossier dans une bibliothèque existante, une vraie bibliothèque dédiée. Ensuite, j’y dépose un PDF de test, par exemple une demande de prêt remplie avec un nom, un montant demandé, des revenus, une durée, bref un document assez réaliste pour tester l’extraction derrière.
Dans Copilot Studio, je crée ensuite le workflow avec un nom explicite, par exemple Loan Application Reviewer. Le déclencheur à utiliser est SharePoint When A File Is Created Properties Only. Son rôle est de démarrer le workflow dès qu’un nouveau fichier est ajouté dans la bibliothèque Loan Applications.
Comment GitHub Agentic Workflows automatise vos reviews ?
Petit détail important : ce déclencheur récupère surtout les propriétés du fichier. Le nom, l’identifiant, le chemin, ce genre d’infos. Il ne récupère pas forcément le contenu complet du PDF. Pour envoyer le document à l’agent d’extraction, il faut ajouter juste après l’action Get File Content. Cette action prend l’identifiant du fichier créé par le déclencheur, puis récupère le binaire du PDF. C’est ce contenu qu’on passera à l’étape suivante.
La configuration ressemble à ça dans l’esprit : je choisis le site SharePoint, je sélectionne la bibliothèque Loan Applications, je branche l’action Get File Content sur l’identifiant du fichier créé, puis je transmets ce contenu à l’agent qui va lire la demande de prêt.
Un truc que j’ai vu souvent chez des clients : le nommage paraît secondaire au début. On se dit que TestFlowFinalV2, ça ira bien. Trois mois plus tard, quand il faut débugger une erreur de permission ou comprendre pourquoi un agent reçoit le mauvais fichier, les noms propres sauvent vraiment du temps.
- Bibliothèque créée : Loan Applications existe bien dans le bon site SharePoint.
- PDF de test présent : Une demande de prêt remplie est déposée dans la bibliothèque.
- Déclencheur configuré : When A File Is Created Properties Only écoute la bonne bibliothèque.
- Action ajoutée : Get File Content récupère le contenu du fichier avec le bon identifiant.
- Permissions OK : Le compte utilisé par Copilot Studio peut lire les fichiers SharePoint.
Comment extraire les champs du PDF ?
Comment créer un agent IA local en streaming ?
Je préfère isoler l’extraction PDF dans un agent dédié, parce que c’est une étape fragile. Si l’agent commence à interpréter, corriger ou “améliorer” les données, tout le workflow derrière devient bancal. Dans Copilot Studio, je crée donc un agent séparé, par exemple Extract PDF Document Fields, avec une seule mission : lire le contenu reçu depuis l’action Get File Content et renvoyer les champs du formulaire.
Son rôle est très limité. Il ne valide pas la demande. Il ne décide pas si le prêt est acceptable. Il ne reformule rien. Il extrait ce qui est écrit dans le PDF, point. C’est un détail, mais chez un client, c’est souvent là que les workflows IA partent en vrille : l’IA veut aider, alors qu’on lui demande juste de copier proprement.
Instructions à coller dans l’agent : Extrais les champs du formulaire de demande de prêt à partir du contenu PDF fourni par l’action Get File Content. Conserve les valeurs exactement comme elles apparaissent dans le document. Ne reformate pas les montants, les dates ou les identifiants. Ne devine pas les champs manquants. Laisse les champs vides quand ils sont vides dans le document. Ne corrige pas les fautes, ne complète pas les informations, ne reformule pas les réponses. Retourne uniquement les propriétés demandées dans la sortie structurée.
Dans Copilot Studio, je définis ensuite une sortie structurée. C’est important parce que les étapes suivantes vont travailler sur des champs stables, pas sur un bloc de texte généré par l’IA. Un booléen, c’est juste une valeur vrai ou faux. Un nombre, c’est une valeur numérique exploitable dans une règle. C’est exactement le genre de détail qui fait la différence entre une démo sympa et un workflow utilisable.
| Propriété | Type attendu |
| Applicant_ID | Texte |
| Applicant_Name | Texte |
| Texte | |
| Phone | Texte |
| Employment_Status | Texte |
| Employed | Booléen |
| Unemployed | Booléen |
| Annual_Income | Nombre |
| Loan_Amount_Requested | Nombre |
| Loan_Purpose | Texte |
Pour tester, je publie le workflow, je supprime le PDF déjà présent dans Loan Applications, puis je recharge le même fichier ou un nouveau formulaire. Le déclencheur repart proprement, l’action Get File Content transmet le contenu à l’agent, et je vérifie que les valeurs renvoyées correspondent bien au formulaire. Si un champ est vide dans le PDF, il doit rester vide dans la sortie. Pas de magie. Pas d’invention.
Comment valider et enrichir les données ?
Après l’agent d’extraction, je ne laisse jamais les données partir directement vers la suite du workflow. Je rajoute une couche simple, froide, déterministe. Pas de magie IA ici. Juste des règles codées qui disent clairement si un champ est acceptable ou pas.
Dans Power Automate, j’initialise une variable varRulesEngine en type array. Chaque objet du tableau représente une règle avec le nom du champ, la règle appliquée, un résultat booléen, et un message d’erreur si ça échoue. Cette étape ne remplace pas l’IA. Elle verrouille ce qui ne doit pas être interprété : format d’identifiant, cohérence des cases à cocher, contraintes numériques. J’ai vu trop de workflows casser parce qu’un modèle avait “compris” un champ, mais pas respecté une règle métier basique.
Une structure simple peut ressembler à ça : Pour le champ Applicant_ID, j’applique la règle de préfixe avec startsWith(outputs(‘Extract_PDF_Document_Fields’)?[‘Applicant_ID’], ‘APP-‘) pour vérifier que l’identifiant commence bien par APP-. Pour les champs Employed et Unemployed, j’utilise not(equals(outputs(‘Extract_PDF_Document_Fields’)?[‘Employed’], outputs(‘Extract_PDF_Document_Fields’)?[‘Unemployed’])) pour éviter que les deux cases aient la même valeur. Pour Annual_Income, j’utilise greater(outputs(‘Extract_PDF_Document_Fields’)?[‘Annual_Income’], 0) pour contrôler que le revenu annuel est positif. Pour Loan_Amount_Requested, j’utilise greater(outputs(‘Extract_PDF_Document_Fields’)?[‘Loan_Amount_Requested’], 0) pour vérifier que le montant demandé est supérieur à zéro.
Attention à un détail très concret : les noms d’actions doivent être adaptés à votre workflow réel. Copilot Studio et Power Automate peuvent générer des noms techniques différents selon votre configuration. Chez vous, l’action ne s’appellera peut-être pas Extract_PDF_Document_Fields. Donc je ne vends pas du copier-coller magique. Je reprends toujours le nom exact visible dans Power Automate.
Une fois ces contrôles passés, j’ajoute l’agent de connaissance SharePoint. Lui peut consulter les documents internes stockés dans SharePoint pour enrichir ou vérifier certains éléments du dossier : critères de politique de prêt, consignes de traitement, règles métier documentées. Mais je reste prudent. L’agent ne doit pas inventer une décision. Il doit s’appuyer sur les règles disponibles et les données extraites.
| Type de contrôle | Responsable | Exemples |
| Contrôles déterministes | Règles codées dans varRulesEngine | Préfixe d’identifiant, cases à cocher incompatibles, montant supérieur à zéro, revenu positif |
| Contrôles contextuels | Agent de connaissance SharePoint | Politique de prêt, consignes internes, exceptions documentées, critères métier à interpréter |
Comment envoyer la réponse finale ?
À ce stade, je préfère ne pas laisser l’agent principal écrire lui-même la réponse finale. Je confie ça à un agent séparé, que j’appelle souvent Email Response Writer. Son boulot est simple : transformer les résultats du workflow en email propre, clair, poli, et utilisable par le demandeur.
Cet agent reçoit uniquement les informations utiles. Le nom du demandeur, son email, les champs extraits du PDF, les résultats des règles, la décision finale d’acceptation ou de rejet, et les raisons principales. Il ne refait pas les calculs. Il ne réinterprète pas les règles. Il ne cherche pas à être plus malin que le workflow. Il rédige.
Je colle généralement des instructions comme celles-ci dans l’agent :
Rédige un email court au demandeur.
Mentionne clairement la décision : acceptée ou rejetée.
Explique les raisons principales en langage simple.
Ne révèle pas de raisonnement interne inutile.
Ne crée aucune nouvelle règle.
Ne promets rien qui n'est pas présent dans les résultats du workflow.
Garde un ton professionnel, clair et poli.
Si la demande est rejetée, reste factuel et respectueux.
Si la demande est acceptée, indique simplement les prochaines étapes si elles sont fournies dans les données du workflow.Ensuite, j’ajoute une action dédiée pour envoyer l’email. Dans Copilot Studio, ça passe souvent par une action Power Automate ou un connecteur email, selon votre stack. Le destinataire, c’est l’adresse Email extraite du PDF. Le corps du message, c’est le contenu généré par l’agent Email Response Writer. L’objet doit rester clair, par exemple : Review of your loan application.
Avant de brancher ça sur de vrais demandeurs, je teste toujours avec une adresse contrôlée. Une adresse interne, ou une boîte de recette. Ça permet de vérifier le rendu, les variables, les accents, les cas de rejet, les cas d’acceptation. J’ai déjà vu des workflows très propres envoyer un email bizarre juste parce qu’un champ était vide ou mal mappé.
En production, j’aime bien garder une étape humaine au début. Au moins sur les premiers dossiers. Quelqu’un vérifie la qualité des extractions, les rejets, et le ton des emails. Une automatisation de décision qui part trop vite sans garde-fou, ça peut faire gagner du temps très vite, mais aussi créer des erreurs à grande échelle.
Le flux complet devient assez simple. Le PDF est déposé dans SharePoint. Le workflow se déclenche. Les données sont extraites. Les règles métier évaluent le dossier. La décision est produite avec ses raisons. L’agent Email Response Writer rédige le message final. L’action email l’envoie au demandeur avec le bon destinataire, le bon objet, et un contenu compréhensible.
Et si votre workflow IA devenait enfin contrôlable ?
Un workflow multi-agent dans Copilot Studio marche bien quand chaque bloc a un vrai rôle. SharePoint déclenche le processus, l’agent d’extraction lit le PDF, les règles valident les champs, l’agent de connaissance apporte du contexte, l’agent de rédaction prépare l’email, puis l’automatisation l’envoie. Ce découpage évite le gros prompt impossible à maintenir. Il rend aussi les tests plus simples, parce qu’on sait où regarder quand un résultat paraît étrange. Pour moi, c’est la bonne manière d’amener l’IA dans un process business : moins de magie, plus de contrôle. Et pour vous, le bénéfice est clair : traiter plus vite sans perdre la maîtrise.
FAQ
- Qu’est-ce qu’un workflow multi-agent dans Copilot Studio ?
C’est un workflow composé de plusieurs agents spécialisés. Au lieu de demander à un seul agent de tout faire, on sépare les tâches : extraction du PDF, validation des champs, enrichissement avec SharePoint, rédaction de l’email. C’est plus simple à tester et plus fiable en production. - Pourquoi utiliser SharePoint comme déclencheur ?
SharePoint sert de point d’entrée clair. Quand un fichier est ajouté dans une bibliothèque comme Loan Applications, le workflow démarre automatiquement. Le déclencheur récupère les propriétés du fichier, puis une action Get File Content permet de transmettre le PDF à l’agent d’extraction. - L’agent peut-il décider seul si le prêt est accepté ?
Je préfère éviter. L’agent peut aider à lire, structurer et rédiger, mais les règles de décision doivent rester explicites quand elles sont déterministes. Par exemple, vérifier un identifiant, un revenu annuel ou un montant demandé se fait mieux avec des expressions de validation. - À quoi sert l’agent de connaissance SharePoint ?
Il sert à apporter du contexte depuis des documents internes, par exemple des consignes, politiques de prêt ou règles métier stockées dans SharePoint. Il ne doit pas inventer de règles. Il enrichit le traitement avec les informations disponibles. - Comment tester ce type de workflow avant production ?
Je teste chaque étape séparément. D’abord le déclencheur SharePoint, puis la récupération du fichier, puis l’extraction des champs, ensuite les règles, puis l’email. Je garde aussi une validation humaine au début, surtout si le workflow envoie de vraies réponses à des demandeurs.
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. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes sur des sujets très concrets : données, automatisation, IA opérationnelle, qualité de mesure et industrialisation des workflows. J’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez mettre en place des automatisations IA utiles, propres et maintenables, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’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 propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, 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.