Copilot Studio peut-il valider avec un humain ?

Copilot Studio peut faire valider une décision par un humain avant d’agir. C’est le bon garde-fou quand l’agent tombe sur un cas risqué, flou ou imprévu. Je vous montre comment penser ce human-in-the-loop avec Teams, e-mail et une réponse réutilisée par l’agent.

Pourquoi ajouter une validation humaine ?

J’ajoute une validation humaine quand une décision d’agent peut coûter cher, créer une erreur métier ou sortir du cadre prévu.

Dans Copilot Studio, le principe du human-in-the-loop, c’est assez simple : l’agent avance seul tant que le cas est clair, puis il s’arrête pour demander un avis humain quand le niveau de risque monte. “Human-in-the-loop”, ça veut juste dire qu’on remet une personne dans la boucle de décision au bon moment.

Un agent autonome peut très bien gérer une demande standard, résumer une information, orienter un utilisateur, préparer une réponse ou déclencher une action prévue. Mais il peut aussi tomber sur une situation ambiguë. Une demande client un peu tendue. Une réponse sensible. Une information qui manque. Une action business qui aurait un impact réel si elle était mal exécutée.

Dans ces cas-là, je préfère que l’agent dise en gros : “Là, je ne tranche pas seul.” Et c’est sain. Le but n’est pas de ralentir l’automatisation. Le but, c’est de placer l’humain là où il apporte vraiment de la valeur : jugement, contexte, responsabilité.

Quelques cas très concrets où je mets souvent une validation humaine :

• Validation d’une réponse sensible avant de l’envoyer à un client.
• Arbitrage sur une demande client qui sort du process habituel.
• Confirmation avant une action business, comme modifier un statut, lancer une demande ou transmettre une information engageante.
• Contrôle avant d’envoyer une information par e-mail ou Teams, surtout si elle contient des données internes ou un ton délicat.

Chez les clients, le vrai problème n’est pas que l’IA ne sait pas répondre. C’est qu’on oublie parfois de définir quand elle doit s’arrêter. Et quand cette limite n’est pas claire, on demande trop à l’agent. Ou pas assez à l’humain.

Cas	Décision	Exemple
Agent autonome suffisant	L’agent peut répondre seul	Question fréquente, information publique, procédure simple.
Validation humaine recommandée	L’agent prépare, l’humain confirme	Réponse client sensible, demande ambiguë, e-mail important.
Blocage obligatoire	L’agent doit s’arrêter	Action à fort impact, risque légal, donnée confidentielle, décision hors cadre.

Comment l’agent demande-t-il un avis ?

Oui, l’agent peut demander un avis humain. Dans un scénario Copilot Studio, il peut envoyer une demande dans Teams ou par e-mail, attendre une réponse, puis utiliser cette réponse pour décider de la suite. C’est souvent là que le “human in the loop” devient concret, pas juste un concept sympa dans une slide.

Le flux est assez simple à comprendre. L’agent détecte un cas qui dépasse son seuil de confiance, ou une situation sensible. Il prépare une question claire, ajoute le contexte utile, envoie ça à la bonne personne, récupère la décision, puis reprend son raisonnement. Dans l’écosystème Microsoft, Copilot Studio peut s’appuyer sur des actions et des flux Power Platform pour déclencher ces échanges dans Teams ou par e-mail, selon l’architecture choisie. J’ai déjà vu des projets où Teams était parfait pour les validations rapides, alors que l’e-mail restait plus adapté quand il fallait garder une trace formelle.

Le point important, c’est la qualité de la demande. Si l’agent écrit “Pouvez-vous valider ?”, personne ne sait quoi faire. La validation devient un goulot d’étranglement. Une bonne demande doit contenir le résumé, le risque, les options possibles et ce qu’on attend exactement comme réponse.

Un message réutilisable peut ressembler à ça. Ce n’est pas du code applicatif, juste une structure HTML propre pour cadrer la décision humaine.

<p><strong>Validation demandée</strong></p>

<p><strong>Résumé :</strong> Le client demande un remboursement de 480 € pour une commande livrée en retard.</p>

<p><strong>Risque identifié :</strong> Le montant dépasse le seuil automatique de 300 €, et l’historique client contient déjà deux remboursements récents.</p>

<p><strong>Décision attendue :</strong> Merci de choisir une option.</p>

<ul>
  <li>Approuver le remboursement</li>
  <li>Refuser le remboursement</li>
  <li>Demander plus d’informations</li>
</ul>

Une fois que la réponse humaine revient, le sujet change complètement. Le vrai enjeu n’est plus d’obtenir un avis, mais de savoir comment l’agent l’interprète, le sécurise et l’utilise pour continuer sans partir dans tous les sens.

Comment exploiter la réponse humaine ?

Une réponse humaine n’a de valeur que si l’agent peut s’en servir pour décider quoi faire ensuite. Si Copilot Studio reçoit juste un commentaire du type “ok pour moi”, mais que rien n’est branché derrière, on n’a pas une validation. On a une note dans un coin.

Je préfère traiter la réponse comme un signal de routage. L’humain ne donne pas seulement son avis, il choisit la prochaine direction du workflow. C’est ça qui rend l’agent vraiment pilotable.

La logique peut rester très simple au départ :

• Si l’humain approuve, l’agent continue l’action prévue, par exemple envoyer un email, créer une demande, mettre à jour une ligne dans Dataverse ou déclencher un flux Power Automate.
• Si l’humain refuse, l’agent bloque l’action, garde une trace de la décision et peut prévenir la personne concernée.
• Si l’humain demande plus d’informations, l’agent revient collecter les éléments manquants, puis relance la validation avec un contexte plus clair.

Voilà le genre de pseudo-règles que j’utilise pour poser la logique avant de configurer l’agent. Ce n’est pas un code Copilot Studio universel, c’est une façon lisible de cadrer le comportement attendu.

Si réponse humaine = "approuvé"
    Alors poursuivre l’action prévue

Si réponse humaine = "refusé"
    Alors arrêter le workflow et enregistrer le motif

Si réponse humaine = "besoin de précision"
    Alors demander les informations manquantes
    Puis revenir vers l’humain pour une nouvelle validation

Dans mes projets data et automatisation, je préfère limiter les réponses possibles au début. Trois choix clairs valent souvent mieux qu’un champ libre. Moins de liberté dans la validation, c’est souvent plus de fiabilité dans le workflow. J’ai déjà vu des automatisations bloquées juste parce qu’une personne avait répondu “ça me semble bon” au lieu de “approuvé”. Pour un humain, c’est pareil. Pour une machine, pas toujours.

Réponse humaine	Action de l’agent	Risque évité
Approuvé	L’agent continue l’action prévue	Éviter un blocage inutile du processus
Refusé	L’agent arrête l’action et conserve la décision	Éviter une action non validée ou risquée
Besoin de précision	L’agent collecte les données manquantes puis redemande validation	Éviter une décision prise avec un contexte incomplet

Le point important, c’est que la réponse humaine doit orienter le comportement suivant de l’agent. Pas décorer l’historique de conversation.

Quelles bonnes pratiques éviteront les dérives ?

Pour éviter les dérives, je cadre trois choses dès le départ : quand l’agent doit demander une validation, comment la décision est tracée, et ce qu’il fait si personne ne répond. Dans Copilot Studio, surtout quand l’agent sollicite quelqu’un via Teams ou par e-mail, le flou coûte cher. Un agent ne doit pas rester bloqué pendant deux jours sans savoir s’il attend, s’il relance, ou s’il annule.

Je définis toujours les cas qui nécessitent une validation humaine. Pas “tout ce qui est important”, c’est trop vague. Plutôt des règles concrètes : montant supérieur à 500 €, client sensible, donnée manquante, action irréversible, réponse avec impact juridique ou commercial. Là, l’humain apporte un vrai contrôle.

Situation	Comportement attendu
Demande simple et faible risque.	L’agent exécute seul et trace l’action.
Montant ou enjeu au-dessus du seuil.	L’agent demande une validation Teams ou e-mail.
Aucune réponse après le délai prévu.	L’agent relance une fois, puis arrête ou escalade.
Validation refusée.	L’agent explique l’arrêt et ne contourne pas la décision.

Je limite aussi le nombre d’approbateurs. Si trois personnes peuvent répondre, personne ne se sent vraiment responsable. Je préfère un approbateur principal, un remplaçant, et une règle claire en cas d’absence. C’est beaucoup plus propre dans le flux Copilot Studio.

Je garde une trace simple de chaque demande : qui a validé, quand, sur quelle base, avec quel message envoyé par l’agent. Pas besoin d’un roman. Mais si un client me demande pourquoi une action a été lancée, je dois pouvoir retrouver la décision.

Les messages doivent être courts. Un bon message de validation dit ce qui est demandé, pourquoi, le risque, et les choix possibles. Approuver. Refuser. Demander plus d’infos. Si le message ressemble à un rapport de consultant, il ne sera pas lu sérieusement.

Je teste autant les refus que les validations. C’est souvent là que les bugs apparaissent. L’agent continue alors qu’il devrait s’arrêter, ou il relance sans fin, ou il envoie une réponse trop vague à l’utilisateur.

Le piège, franchement, c’est de faire valider trop de choses. Si tout demande une approbation, plus personne ne répond sérieusement. La validation humaine ne remplace pas la gouvernance, elle la rend opérationnelle dans le flux. Le bon design, c’est un agent assez autonome pour gagner du temps, mais assez prudent pour ne pas décider seul quand l’enjeu dépasse son cadre.

Alors, où faut-il placer l’humain dans vos agents ?

Je vois la validation humaine comme une ceinture de sécurité pour Copilot Studio. L’agent peut avancer vite sur les cas simples, puis demander un avis quand la décision devient sensible, ambiguë ou trop risquée. Teams et l’e-mail sont pratiques parce qu’ils ramènent la validation là où les équipes travaillent déjà. Le point clé, c’est la suite : l’agent doit utiliser la réponse pour continuer, bloquer ou demander plus d’informations. Si vous cadrez bien les seuils, les messages et les scénarios de refus, vous gagnez du temps sans perdre le contrôle. Et c’est ça le vrai bénéfice pour vous.

FAQ

• Qu’est-ce que le human-in-the-loop dans Copilot Studio ?
  C’est le fait de faire intervenir un humain dans le flux de décision d’un agent. L’agent ne décide pas seul sur certains cas. Il demande une validation, récupère la réponse, puis adapte son action.
• Pourquoi faire valider une décision d’agent IA ?
  Parce qu’un agent peut rencontrer un cas imprévu, sensible ou trop risqué. La validation humaine évite qu’une automatisation prenne une décision business importante sans contrôle.
• Copilot Studio peut-il demander une validation via Teams ?
  Oui, le scénario consiste à envoyer une demande à un humain dans Teams, récupérer sa réponse, puis l’utiliser pour orienter la suite du comportement de l’agent.
• Peut-on utiliser l’e-mail pour une validation humaine ?
  Oui, l’e-mail peut servir de canal de validation. C’est utile quand les équipes ne travaillent pas toutes dans Teams ou quand une trace écrite simple suffit.
• Quel est le risque si on ajoute trop de validations ?
  L’agent perd son intérêt. Si chaque action attend une approbation, l’automatisation devient lente et les humains finissent par valider machinalement. Il faut réserver la validation aux vrais cas à risque.

 

 

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 rendre leurs outils data, IA et automatisation vraiment exploitables, pas juste impressionnants en démo. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer vos agents IA, vos workflows ou vos automatisations business, contactez-moi.