Copilot Studio peut-il demander une revue humaine ?

Copilot Studio peut automatiser une décision puis passer la main à un humain quand le risque est trop flou. Ici, je vous montre le scénario propre pour vérifier une demande de prêt avec SharePoint, un agent IA, une sortie structurée et une validation humaine via Outlook ou Teams.

Pourquoi ajouter une revue humaine ?

La revue humaine sert à éviter qu’un agent IA prenne seul une décision quand le motif du prêt n’est pas reconnu, ambigu ou risqué.

Dans un cas bancaire simple, une demande de prêt arrive avec trois informations clés : le nom légal complet du client, le montant demandé et le motif du prêt. L’agent IA compare ce motif à une liste de motifs déjà évalués. Si le motif est connu, il peut classer la demande en Allowed ou Flagged. Si le motif ne correspond pas clairement, il renvoie Human-Review et déclenche une demande à un agent humain.

C’est ça le point important. L’IA ne remplace pas le contrôle. Elle accélère ce qui est clair et elle isole ce qui mérite une vraie décision humaine. Pour un lecteur business, ça veut dire moins de temps perdu sur les dossiers évidents. Pour un lecteur technique, ça veut dire un flux plus robuste, avec une sortie prévue pour les cas limites au lieu d’un bricolage après coup.

J’ai souvent vu des automatisations casser parce qu’on voulait tout décider automatiquement dès la première version. Sur le papier, ça paraît efficace. Dans la vraie vie, les utilisateurs écrivent des motifs bizarres, incomplets, trop vagues, ou mélangent plusieurs intentions dans une seule phrase. Un prêt “pour trésorerie urgente suite à litige fournisseur”, ce n’est pas forcément noir ou blanc. Si l’agent force une décision, on crée du risque. Si l’agent sait dire “je ne sais pas”, on garde le contrôle.

Le bon design, pour moi, c’est de garder l’humain dans la boucle sur les cas limites. Pas partout. Juste là où ça compte. Copilot Studio devient alors un accélérateur de traitement, pas une boîte noire qui décide sans garde-fou.

Quelles listes SharePoint préparer ?

Il faut préparer deux listes SharePoint simples : Bank Loan Applications pour collecter les demandes entrantes, et Loan Purposes pour donner à l’agent une base de comparaison fiable.

Je garde volontairement ça simple. Si les listes sont trop riches dès le départ, on finit souvent avec un agent qui hésite, qui interprète trop, ou qui demande une revue humaine pour de mauvaises raisons. J’ai déjà vu ça chez un client : le problème ne venait pas de Copilot Studio, mais d’un référentiel métier trop flou.

La première liste, Bank Loan Applications, contient les demandes de prêt soumises par les utilisateurs. Elle doit avoir au minimum ces champs :

• Full Legal Name : Le nom légal complet du demandeur.
• Requested Amount : Le montant demandé.
• Stated Purpose : Le motif déclaré du prêt.

À partir de ces champs, je crée un formulaire SharePoint simple. C’est ce formulaire qui permet à l’utilisateur de soumettre sa demande. Pas besoin de surcharger à ce stade. L’objectif est de récupérer une demande propre, lisible, exploitable par l’agent.

La seconde liste, Loan Purposes, sert de référentiel de comparaison. C’est la base de vérité de l’agent. Elle contient les motifs de prêt déjà évalués et leur catégorie métier.

• Purpose : Le motif de prêt connu, par exemple rénovation, consolidation de dettes, études, vacances, jeux d’argent, cryptomonnaies.
• Category : La décision associée au motif, avec deux valeurs simples : Allowed ou Flagged.

Certains motifs peuvent être autorisés, comme rénovation, consolidation de dettes ou études. D’autres peuvent être signalés, comme vacances, jeux d’argent ou cryptomonnaies. Ça dépend vraiment de votre politique interne. Le point important, c’est que l’agent ne décide pas dans le vide. Il compare le motif déclaré avec une liste validée par le métier.

Mon conseil pratique : gardez un vocabulaire court, stable et relu par le métier. Sinon, vous transformez l’agent IA en devinette permanente. Et dans un workflow de revue humaine, ça finit vite par créer du bruit au lieu d’aider.

Comment déclencher le workflow ?

Le workflow se déclenche dès qu’un nouvel élément est créé dans la liste SharePoint Bank Loan Applications.

Dans le chapitre précédent, la demande passait par un formulaire SharePoint. C’est lui qui crée l’élément dans la liste. À partir de là, cet élément devient l’événement de départ. Le connecteur SharePoint surveille la liste, repère la nouvelle ligne, récupère ses données, puis lance le traitement côté workflow.

J’aime bien cette approche parce qu’elle est simple, lisible, et surtout crédible dans un environnement Microsoft. SharePoint sert de point d’entrée métier. Les utilisateurs remplissent une demande sans se poser de question technique. Le workflow, lui, réagit à la création de l’élément. C’est exactement le genre de mécanique qu’on voit souvent chez des clients qui veulent automatiser sans reconstruire tout leur système.

Concrètement, le déclencheur utilise la liste Bank Loan Applications et la vue All Items. La vue sert à exposer les éléments que le connecteur doit surveiller. Dès qu’une nouvelle demande arrive, le flux récupère l’élément SharePoint et garde en mémoire les informations utiles pour la suite.

Les données importantes à conserver sont assez limitées, mais elles doivent être propres. Le flux doit garder le nom légal complet, le montant demandé, le motif déclaré, et surtout l’identifiant de l’élément SharePoint. Cet identifiant est souvent sous-estimé, alors qu’il devient vite indispensable. Il permettra plus tard de retrouver la bonne demande, de mettre à jour son statut, ou de conserver la trace de la décision associée.

À ce stade, je ne cherche pas encore à décider si la demande est acceptée, refusée, ou envoyée en revue humaine. Le but est plus simple. Le workflow doit capter l’événement, récupérer les bonnes données, et préparer une base fiable pour le traitement automatique ou humain qui suivra.

• Vérifier que le formulaire crée bien un élément dans la liste Bank Loan Applications.
• Vérifier que le connecteur SharePoint surveille la bonne liste.
• Vérifier que la vue utilisée est bien All Items.
• Vérifier que le flux récupère le nom légal complet, le montant demandé et le motif déclaré.
• Vérifier que l’identifiant SharePoint de l’élément est conservé pour la suite.

Comment l’agent compare les motifs ?

L’agent compare le motif déclaré par le client avec les entrées de la liste Loan Purposes récupérées dans SharePoint.

Avant d’appeler l’agent, je fais récupérer toutes les lignes de cette liste par le workflow. C’est important. L’agent a besoin d’une base claire pour comparer. Il ne doit pas inventer une catégorie ou juger “au feeling”. Il travaille à partir d’un référentiel fourni par le métier, avec les motifs autorisés, surveillés, ou à envoyer en revue humaine.

Je vois cette étape comme un garde-fou. Dans un cas client, on avait laissé l’agent interpréter seul des motifs de prêt. Résultat, il classait parfois “voyage” et “vacances” différemment alors que le métier voulait les traiter pareil. Depuis, je préfère lui donner la liste SharePoint complète et lui demander de comparer avec cette source uniquement.

Les instructions données à l’agent doivent être très simples. Il reçoit stated_purpose, donc le motif déclaré par le client, puis la liste des motifs disponibles dans Loan Purposes. Il compare les deux.

• Si un match existe, il renvoie le motif exact trouvé dans SharePoint dans matching_purpose.
• Il renvoie aussi la catégorie associée à ce motif dans category.
• Si aucun match n’existe, il laisse matching_purpose vide et met category à Human-Review.

La sortie doit rester structurée avec trois champs, toujours les mêmes.

• Champ stated_purpose : Le motif déclaré par le client.
• Champ matching_purpose : Le motif exact trouvé dans la liste SharePoint, ou vide si rien ne correspond.
• Champ category : La catégorie associée, ou Human-Review si aucun match n’est trouvé.

Cette structure rend le If Else fiable. Si l’agent répond en texte libre du style “ce motif semble suspect”, l’automatisation devient fragile. Le workflow ne sait pas toujours quoi tester. Avec trois champs fixes, c’est net.

Exemple simple. Si le motif déclaré est vacances, que vacances existe dans SharePoint et que sa catégorie est Flagged, l’agent renvoie stated_purpose = vacances, matching_purpose = vacances, category = Flagged.

Autre exemple. Si le motif déclaré est achat de bateau et qu’aucun motif ne correspond dans SharePoint, l’agent renvoie stated_purpose = achat de bateau, matching_purpose vide, category = Human-Review.

Quand envoyer la demande à un humain ?

J’envoie la demande à un humain dès que la sortie de l’agent contient une valeur category égale à Human-Review.

La logique est assez simple. Je récupère la catégorie renvoyée par l’agent, puis je passe dans un bloc If Else. Si category vaut Human-Review, le workflow déclenche une demande de revue humaine, typiquement via Outlook ou Teams. Si category vaut Allowed ou Flagged, le traitement peut continuer automatiquement, selon les règles internes prévues.

Je préfère garder cette logique très lisible. Pas besoin de cacher ça dans dix conditions imbriquées. On parle d’une décision métier sensible, donc il faut pouvoir comprendre vite pourquoi le dossier est parti en validation humaine. Chez un client, c’est souvent là que les problèmes commencent : l’automatisation marche, mais personne ne sait expliquer pourquoi une demande a été bloquée ou escaladée.

Teams ou Outlook sont cohérents pour ce type de validation, parce qu’ils permettent de contacter directement la personne responsable dans son environnement de travail. L’humain reçoit la demande, répond via un formulaire ou un message, et sa réponse guide la suite du processus. Je ne détaille pas ici les étapes finales de mise à jour et de test, parce que ça dépend du flux exact, des outils connectés et des règles de l’organisation.

Dans la demande envoyée à l’humain, je transmets au minimum les informations utiles pour décider vite et correctement :

• Nom légal complet de la personne ou de l’entité concernée.
• Montant demandé.
• Motif déclaré de la demande.
• Raison de l’escalade vers un humain.
• Catégorie renvoyée par l’agent.
• Motif correspondant, s’il existe.

Je conserve aussi la réponse humaine. Pas juste pour faire joli dans un historique. Pour tracer la décision, comprendre ce qui s’est passé, et pouvoir justifier le traitement plus tard. Sur ce type de flux, la traçabilité vaut presque autant que l’automatisation.

• Allowed : Le dossier peut continuer automatiquement selon les règles prévues.
• Flagged : Le dossier peut suivre un traitement automatique spécifique, souvent plus prudent.
• Human-Review : Le workflow envoie une demande à un humain via Teams ou Outlook.

Alors on automatise quoi et on garde quoi pour l’humain ?

Copilot Studio est très utile quand on lui donne un cadre net. Ici, SharePoint collecte la demande, une liste de motifs sert de référentiel, l’agent compare le motif déclaré et renvoie une sortie structurée. Si le cas est connu, le workflow avance. Si le cas est flou ou absent du référentiel, l’humain reprend la main via Outlook ou Teams. C’est exactement le bon compromis à mon avis. On automatise les décisions simples, on garde du contrôle sur les zones sensibles. Le bénéfice pour vous, c’est un process plus rapide, plus traçable et moins risqué.

FAQ

• À quoi sert la revue humaine dans Copilot Studio ?
  Elle sert à reprendre la main quand l’agent IA ne peut pas classer une demande avec assez de certitude. Dans ce scénario, si le motif du prêt n’existe pas dans la liste des motifs connus, la demande passe en Human-Review au lieu d’être traitée automatiquement.
• Pourquoi utiliser SharePoint dans ce workflow ?
  SharePoint sert à deux choses simples. Une liste collecte les demandes de prêt entrantes. Une autre liste stocke les motifs déjà évalués avec leur catégorie. Ça donne au workflow une base métier claire et facile à maintenir.
• Quelles sorties l’agent doit-il renvoyer ?
  L’agent doit renvoyer une sortie structurée avec stated_purpose, matching_purpose et category. Cette structure permet ensuite au If Else de décider proprement si le flux continue en automatique ou s’il déclenche une revue humaine.
• Quand la catégorie Human-Review est-elle utilisée ?
  Elle est utilisée quand aucun motif de la liste Loan Purposes ne correspond au motif déclaré par le client. Dans ce cas, matching_purpose reste vide et le workflow demande à un humain de trancher.
• Peut-on envoyer la revue humaine dans Teams ou Outlook ?
  Oui, le scénario prévoit une demande envoyée à un agent humain via Outlook ou Teams. L’humain reçoit les informations de la demande, répond via un formulaire ou un message, puis sa réponse guide la suite du processus.

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. J’accompagne des équipes qui veulent automatiser sans perdre le contrôle métier, avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer vos agents IA, vos workflows ou vos automatisations business, contactez-moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

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.