Copilot Studio : créer un agent interne avec approbation humaine

Un agent interne ne devient réellement utile que lorsqu’il sait faire deux choses : répondre avec des informations fiables et faire avancer une demande sans court-circuiter les règles de l’entreprise. Dans Copilot Studio, la combinaison d’un agent conversationnel et d’un flux Power Automate permet précisément ce montage : l’agent collecte le besoin, consulte les connaissances autorisées, puis transmet une demande structurée à un processus comprenant une approbation humaine.

Ce tutoriel prend un cas volontairement concret : un collaborateur demande un ordinateur, un écran ou un accessoire. Le même modèle s’applique à une question de procédure — télétravail, congés, accès applicatif — à condition de séparer clairement la réponse documentaire de l’exécution d’une action.

Définir le périmètre avant de créer l’agent

Commence par écrire une fiche de service d’une page. Elle évite de transformer l’agent en chatbot généraliste dont les réponses deviennent difficiles à contrôler. Dans notre exemple, l’agent couvre deux intentions :

• répondre aux questions sur la politique de matériel et les procédures IT ;
• enregistrer une demande de matériel pour examen par le manager et, selon le cas, l’équipe IT ou les achats.

Définis également ce qu’il ne fait pas : commande directe, modification de budget, création de compte à privilèges, traitement d’informations sensibles non prévues dans le formulaire. Pour ces demandes, l’agent doit expliquer le canal adapté, pas improviser une procédure.

Dans Copilot Studio, crée un nouvel agent dans le bon environnement Power Platform. Ce choix a une incidence directe sur les connecteurs disponibles, les politiques de prévention de perte de données (DLP), les identités et la gouvernance. L’éditeur Microsoft présente Copilot Studio comme une plateforme de création et de gestion d’agents, avec des sources de connaissances, des sujets conversationnels et des actions connectées à des systèmes externes. Consulte aussi la documentation de présentation de Copilot Studio pour vérifier les capacités activées dans ton tenant.

Écrire des instructions qui encadrent les réponses

Les instructions de l’agent ne remplacent ni les droits Microsoft 365 ni la validation métier. Elles fixent toutefois son comportement de base. Rédige-les comme un contrat opérationnel, avec un ton et des limites explicites.

Tu es l’assistant du service interne IT.
Tu réponds uniquement aux questions sur les procédures et le matériel publiés dans les sources approuvées.
Pour une demande de matériel, collecte les informations requises une par une si nécessaire.
Ne promets jamais une approbation, un délai ou une commande.
Avant d’exécuter le workflow, récapitule les données et demande confirmation.
Si une information manque ou si la demande sort du périmètre, oriente l’utilisateur vers le service compétent.
Si le workflow échoue, indique que la demande n’a pas été enregistrée et propose le canal de secours.

Ajoute ensuite un sujet ou une intention dédiée, par exemple « Demander du matériel ». Les formulations attendues peuvent inclure « j’ai besoin d’un écran », « commander un ordinateur » ou « demande de casque ». Prévois aussi un chemin « Question sur le matériel » : il doit privilégier la recherche dans les connaissances, sans appeler le flux.

Brancher des connaissances fiables et limitées

La qualité de l’agent dépend d’abord du corpus qu’on l’autorise à consulter. Ne connecte pas un site intranet entier par réflexe. Sélectionne des documents maintenus, versionnés et compréhensibles : politique d’équipement, catalogue standard, conditions de renouvellement, guide de télétravail, procédure de restitution et contacts d’escalade.

Dans un contexte Microsoft 365, une bibliothèque SharePoint dédiée est souvent plus simple à gouverner qu’une collection de liens dispersés. N’expose que les espaces dont les permissions correspondent à l’audience de l’agent. Vérifie surtout que les documents ne contiennent pas de tarifs confidentiels, de données personnelles ou d’instructions réservées aux administrateurs.

Prépare des contenus adaptés aux questions réelles. Une procédure qui dit « suivre le processus habituel » n’aide ni l’agent ni le collaborateur. Elle doit préciser les critères d’éligibilité, les informations à fournir, les étapes de décision et le délai indicatif lorsqu’il est officiellement communiqué. Pour les réponses à faible confiance, impose une règle : citer la procédure disponible ou rediriger vers le support, plutôt que combler un trou avec une affirmation plausible.

Collecter les variables avant l’appel du workflow

Dans le sujet de demande, fais recueillir des variables structurées. Réduis au maximum la saisie libre : elle complique l’approbation et le reporting. Une configuration utile comprend :

• demandeur : identité récupérée du contexte lorsque c’est possible, sinon confirmée ;
• typeMateriel : ordinateur, écran, casque, téléphone ou accessoire ;
• modeleSouhaite : choix dans un catalogue, ou « besoin non standard » ;
• justification : texte court, avec une question orientée sur le besoin de travail ;
• centreCout et manager : idéalement validés contre une source de référence ;
• dateSouhaitee et lieuLivraison : avec des formats contrôlés.

Avant l’action, affiche un récapitulatif : « Tu demandes un écran 27 pouces, pour le centre de coût X, avec telle justification. Veux-tu envoyer cette demande ? » Cette confirmation est indispensable : un utilisateur peut changer d’avis, corriger un centre de coût ou constater qu’il a choisi le mauvais produit.

Construire le flux Power Automate avec une approbation

Crée un cloud flow appelé depuis l’agent. La documentation Microsoft sur les flows dans Copilot Studio décrit leur rôle : ils permettent à l’agent d’exécuter des automatisations et d’échanger des entrées et sorties avec Power Automate.

Le flux doit recevoir les variables collectées et appliquer les contrôles métier côté workflow, pas seulement dans le dialogue. Un déroulé robuste ressemble à ceci :

1. valider les champs obligatoires et le format des données ;
2. vérifier que le type de matériel fait partie du catalogue autorisé ;
3. créer une demande dans une liste SharePoint, Dataverse ou l’outil de ticketing retenu, avec le statut « En attente d’approbation » ;
4. lancer une action d’approbation vers le manager, avec la justification, le coût estimé si cette donnée est fiable, et un lien vers le ticket ;
5. si le manager approuve, notifier IT ou les achats et passer le ticket à « Approuvé — à traiter » ;
6. si le manager refuse, enregistrer le commentaire et avertir le demandeur ;
7. renvoyer à Copilot Studio un résultat minimal : identifiant de demande, statut et message utilisateur.

Évite de renvoyer au chat les détails de l’approbation ou des informations que le demandeur n’est pas censé voir. Configure les connexions avec des comptes de service ou des mécanismes gouvernés lorsque cela correspond à ta politique, et contrôle les autorisations d’exécution du flow. Une approbation dans Teams ou Outlook est pratique, mais elle n’est pas un modèle de sécurité à elle seule : la liste des approbateurs doit être maîtrisée dans le workflow.

Tester les échecs avant l’ouverture aux équipes

Teste d’abord dans un environnement non productif, avec des comptes représentant un salarié, un manager, un agent IT et un utilisateur sans droits. Ne te contente pas du scénario nominal. Construis un jeu de tests et conserve le résultat attendu pour chaque cas.

• Demande standard : toutes les variables sont présentes, le manager approuve, le ticket et les notifications sont créés une seule fois.
• Refus : le commentaire du manager remonte dans le bon canal sans divulguer d’information superflue.
• Abandon : l’utilisateur ne confirme pas le récapitulatif ; aucun flow ne doit démarrer.
• Hors périmètre : « Peux-tu augmenter mon budget ? » ou « Donne-moi les salaires IT » doit déclencher un refus poli et une orientation, pas une réponse inventée.
• Donnée incohérente : date passée, centre de coût invalide, modèle hors catalogue ou justification vide doivent être bloqués avant l’approbation.
• Échec de connecteur : simule une indisponibilité de SharePoint, Teams ou du ticketing. L’agent doit annoncer que la demande n’a pas été enregistrée, fournir un canal de secours et éviter tout faux numéro de dossier.
• Double envoi : l’utilisateur répète la confirmation ou relance la conversation. Prévois un identifiant de corrélation ou une règle d’idempotence dans le flux.

Enfin, mesure les abandons avant confirmation, les refus, les échecs techniques et les questions non résolues. Ces signaux te diront s’il faut améliorer les documents, les variables ou le workflow — pas seulement le prompt.

Le bon premier déploiement reste volontairement étroit : un catalogue limité, une population pilote et un circuit d’approbation lisible. Une fois les logs et les retours stabilisés, tu peux étendre le même patron à l’accès logiciel, aux demandes RH ou aux procédures d’onboarding.