Agent autonome dans Copilot Studio Module

Vaks PM · Guide d'intégration · Agents IA · Copilot Studio · Août 2026

Ce que couvre ce guide. Comment brancher un agent Copilot Studio qui agit sous sa propre identité d'agent Vaks PM — avec son propriétaire, ses budgets, sa piste d'audit — et qui travaille dans la boucle des agents : il tire des tâches, les réclame, livre, se fait réveiller par un nudge quand on lui assigne du travail. C'est un chemin différent de l'agent Copilot « au nom de l'utilisateur » décrit dans l'autre guide ; commencez par la distinction ci-dessous.

Agent autonome ≠ agent « au nom de l'utilisateur »

Copilot Studio peut brancher Vaks PM de deux façons, qui ne produisent pas la même identité. Choisir la bonne dès le départ évite de tout recâbler :

	Au nom de l'utilisateur	Agent autonome cette page
Qui agit	L'agent emprunte les droits de la personne qui lui parle. Chaque utilisateur se connecte à Vaks avec son propre compte.	L'agent agit comme lui-même — une identité d'agent dédiée, avec un propriétaire humain, un niveau de confiance et des capacités propres.
Identité Vaks	Un utilisateur humain (délégation).	Un acteur de type `AGENT` (jamais un humain).
Authentification	OAuth 2.0 per-user (client pré-enregistré).	Un PAT d'agent présenté en en-tête `X-Api-Key`.
Ce qu'il fait	Répond aux questions d'un collaborateur : rapports, recherches, actions ponctuelles.	Exécute du travail confié : réclame des tâches, produit des livrables, se fait réviser, déclare son coût.
Réveil (nudge)	Sans objet.	Oui — l'agent s'abonne aux nudges pour être réveillé à l'assignation.
Guide	MCP · Copilot Studio (au nom de l'utilisateur)	Cette page.

Les deux peuvent coexister. Rien n'empêche d'avoir, dans la même organisation, un agent d'assistance « au nom de l'utilisateur » pour vos collaborateurs et un ou plusieurs agents autonomes qui exécutent du travail. Ce sont deux agents Copilot Studio distincts, deux connecteurs distincts, deux identités Vaks distinctes.

À quoi ça ressemble — le workflow

De l'assignation d'une tâche à sa revue, voici le trajet complet. Deux systèmes coopèrent : Vaks PM (la gouvernance et le travail) et Microsoft (Power Automate + Copilot Studio, l'exécution de l'agent). Le nudge est le seul signal que Vaks émet vers l'extérieur ; tout le reste du travail passe par le connecteur MCP, avec le PAT de l'agent.

Le workflow d'un agent autonome. Encadrés orange = le nudge sortant et les appels MCP de l'agent ; encadrés sombres = les états Vaks et les étapes côté Microsoft ; flèche pointillée = retour après une demande de changements (un nouveau nudge relance le cycle). L'encart de droite : l'exécution de l'agent a un coût Microsoft distinct — détaillé juste après.

Le coût d'exécution est à part

Faire tourner un agent autonome via Copilot Studio a un coût d'exécution propre, facturé par Microsoft — distinct de l'infrastructure Vaks PM et de tout siège de licence. Deux notions à ne pas confondre :

Coût	Qui facture	De quoi il s'agit
Copilot Credits	Microsoft	Chaque tour de l'agent et chaque appel d'outil consomme des Copilot Credits sur la capacité de votre tenant (pack prépayé ou pay-as-you-go). C'est une facturation Microsoft, hors Vaks PM — à provisionner comme pour tout agent Copilot Studio.
Estimation Vaks (P&L)	Vaks PM (interne)	Pour que ce coût n'échappe pas au compte de résultat du projet, Vaks PM l'estime : un montant dérivé de l'activité de l'agent (une base par tâche + un incrément par appel d'outil), converti en euros via un prix du crédit que vous renseignez. Il apparaît alors dans le P&L au même titre que le travail humain.

Activer l'estimation. Sous Admin → Gestion des agents IA → Policies, activez l'estimation Copilot et renseignez le prix du crédit — sans lui, les crédits sont bien comptés mais le coût s'affiche à ~0 €. L'unité de mesure est ici le crédit, pas le token : un agent Copilot est facturé en crédits Microsoft (contrairement à un agent branché sur une passerelle LLM, mesuré en tokens). Le détail complet — unités, sources de mesure, catalogue de prix — est dans Coût des agents IA.

Prévoyez la capacité côté Microsoft. L'agent ne s'exécute que si votre tenant a de la capacité Copilot Studio — un pack de crédits prépayé ou une billing policy pay-as-you-go (abonnement Azure lié à l'environnement). Cette capacité se gère dans le Power Platform admin center, pas dans Vaks.

Avant de commencer

Activer le connecteur MCP pour l'organisation (Activer et cadrer). Les écritures d'un agent exigent en plus la bascule d'écriture. Sans elle, l'agent reste en lecture seule.
Un projet ouvert aux agents avec un brief — un agent ne peut réclamer du travail que là. Voir gouvernance.
Tester avec un compte normal, pas un Administrateur général. Comme pour l'autre guide, un Global Admin reçoit dans Dataverse un mode d'accès filtré qui casse la lecture des connecteurs custom. Testez avec un compte utilisateur licencié standard. Voir le détail du piège.
Orchestration générative — ce chemin repose sur elle (l'agent choisit ses outils). Prévoyez de l'activer (étape 4).

Étape 1 — Créer l'identité d'agent dans Vaks PM

Ouvrez Admin → Utilisateurs & Identité → Agents :

Créez l'agent : un nom d'affichage, un propriétaire humain (obligatoire — il en reste responsable), un niveau de confiance.
Définissez ses capacités au minimum requis par le travail. Pour la boucle standard : lecture, plus task:update et comment:create. Un agent ne peut jamais obtenir de capacités finance, client, administration ou saisie de temps.
Générez son jeton d'accès (PAT). Il commence par vaks_pat_ et n'est affiché qu'une seule fois — copiez-le immédiatement dans un coffre.

Le PAT porte l'identité et les droits de l'agent. Ses droits effectifs sont l'intersection du rôle, des scopes du jeton et des capacités déclarées. Il n'agit que sur la surface d'API publique et ne touche jamais l'application d'administration privée — même si le compte sous-jacent était privilégié. À l'échelle, vous pouvez remplacer le PAT manuel par un jeton sans secret distribué — voir Authentification des agents.

Étape 2 — Ajouter l'agent comme membre du projet

Un agent ne peut réclamer du travail (ni recevoir de nudge) que sur un projet dont il est membre. Sur le projet ouvert aux agents, ajoutez l'agent comme Contributeur (onglet accès du projet). Sans cette adhésion, l'agent voit l'API mais aucune tâche à réclamer.

Les agents ne sont pas dans l'annuaire des jetons. Ils n'apparaissent pas dans la recherche d'utilisateurs standard. Vous les retrouvez dans la liste des membres du projet une fois ajoutés — et dans l'espace admin des agents. Cette adhésion est aussi ce qui rend l'agent assignable sur une tâche depuis la fiche de tâche, sur un projet ouvert aux agents.

Étape 3 — Créer le connecteur (l'outil MCP)

Contrairement au chemin « au nom de l'utilisateur » (OAuth), un agent autonome se branche par un connecteur personnalisé classique qui présente le PAT en en-tête. Dans Copilot Studio (ou Power Apps → Custom connectors), créez un connecteur personnalisé :

Onglet	Réglage
General	Host = votre domaine Vaks (ex. `vaks-pm.exemple.fr`). Base URL = `/mcp` (l'URL complète du serveur MCP est `https://<votre-domaine>/mcp`).
Security	Type d'authentification = API Key. Parameter name = `X-Api-Key`, Location = Header.
Definition	Une action InvokeServer : `POST /mcp`. C'est le point d'entrée MCP — Copilot Studio fait le `tools/list` derrière.

À la connexion du connecteur, la valeur de la clé API est le PAT brut de l'étape 1 (vaks_pat_…, sans préfixe Bearer).

N'utilisez PAS Authorization: Bearer. Les connecteurs personnalisés Power Platform réservent et retirent l'en-tête Authorization — un PAT placé là n'arrive jamais au serveur, qui répond -32001 Jeton d'accès requis. C'est exactement pour ça que le serveur MCP de Vaks PM lit le jeton, en repli, dans l'en-tête non réservé X-Api-Key. Réglez bien la clé API sur X-Api-Key en Header.

Un agent voit une surface d'outils réduite. Quand le jeton est celui d'un agent, le serveur MCP ne présente qu'une trentaine d'outils utiles à la boucle de travail (réclamer → contexte → décomposer → livrer → run → revue → validation) — une quinzaine seulement si l'agent est en lecture seule —, pas la surface complète (une cinquantaine d'outils). C'est du moindre privilège — et cela passe sous le plafond de 70 outils par agent de Copilot Studio sans réglage manuel.

Étape 4 — Ajouter l'outil à l'agent & activer l'orchestration

Dans votre agent Copilot Studio, onglet Tools → Add a tool, ajoutez le connecteur créé à l'étape 3, et créez / sélectionnez la connexion portant le PAT.
Activez l'orchestration générative (Settings de l'agent). Sans elle, l'agent retombe sur le topic système « Escalate » par défaut et n'appelle aucun outil — il répond « escalating to a representative… » au lieu d'agir.

Vérifier le branchement. Une fois l'outil ajouté et l'orchestration active, un test simple (« liste mes tâches ») doit renvoyer des données réelles de Vaks. Si vous voyez -32001, l'authentification passe encore par Authorization et non X-Api-Key (étape 3).

Étape 5 — Brancher le réveil (nudge)

À ce stade l'agent peut travailler, mais il faut qu'on lui dise quand. C'est le rôle du nudge : quand une tâche lui est assignée, Vaks PM appelle une URL de callback, ce qui déclenche un run de votre flow. Côté Copilot Studio / Power Automate, cela se fait avec le trigger « HTTP Webhook » (de Logic Apps), qui s'abonne et se désabonne tout seul.

Champ du trigger « HTTP Webhook »	Valeur
Subscribe — Method	`POST`
Subscribe — URI	`https://<votre-domaine>/api/v1/me/webhook-subscriptions`
Subscribe — Body	`{ "callbackUrl": "@{listCallbackUrl()}" }`
Subscribe — Headers	`X-Api-Key: vaks_pat_…` (le PAT de l'agent) · `Content-Type: application/json`
Unsubscribe — Method	`DELETE`
Unsubscribe — URI	la même que le Subscribe URI (sans id) — `https://<votre-domaine>/api/v1/me/webhook-subscriptions`
Unsubscribe — Headers	`X-Api-Key: vaks_pat_…`

Au premier run, le trigger appelle le Subscribe URI ; Vaks PM enregistre le callback et renvoie l'URL de désinscription dans l'en-tête Location, que le trigger mémorise. À chaque task.assigned ensuite, le flow démarre — réveillez alors l'agent et faites-lui tirer et réclamer la tâche (vaks_claim_task / vaks_claim_next_task).

Un seul flow pour tous les agents ? Au lieu d'un flow par agent avec son PAT, abonnez une clé d'organisation (vaks_org_…) scopée nudge:manage — générée en un clic via Admin → Gestion des agents IA → Réveils d'agents → Générer la clé de connexion. Le même callback reçoit alors les nudges de tous les agents ; aiguillez sur l'en-tête X-Vaks-Agent-Email (un Switch) pour réveiller le bon. Le détail des deux modes est dans le guide Réveil des agents.

Le nudge ne porte aucune autorité. Il ne fait que réveiller le flow avec un taskId / projectId / agentId signés en HMAC. Tout le travail réel — réclamer, lire le contexte, livrer — se fait ensuite avec le PAT de l'agent via l'outil MCP. Vérifiez la signature (X-Vaks-Signature) avant d'agir : voir vérifier la signature.

Étape 6 — Publier & tester

Publiez l'agent. L'orchestration générative doit rester active.
Assignez une tâche à l'agent sur le projet ouvert aux agents (depuis la fiche de tâche). Un nudge task.assigned doit partir — visible dans Admin → Gestion des agents IA → Réveils d'agents → Journal des livraisons.
Le flow démarre, l'agent réclame la tâche, la traite et la soumet en revue — le statut passe à En revue. Chaque action apparaît dans le journal d'audit comme réalisée par un acteur de type AGENT, avec le propriétaire et une justification.

Si l'assignation déclenche un run, que l'agent réclame et livre, et que le journal d'audit attribue le tout à l'agent (pas à un humain), la boucle autonome fonctionne : l'agent exécute du travail sous sa propre identité, borné par ses capacités, ses budgets et les policies du projet.

Récapitulatif des paramètres

Élément	Valeur
URL du serveur MCP	`https://<votre-domaine>/mcp`
Action du connecteur	`POST /mcp` (InvokeServer)
Authentification	API Key — `X-Api-Key` en Header, valeur = PAT brut `vaks_pat_…`
Orchestration	Générative, activée
Capacités agent (boucle standard)	lecture + `task:update` + `comment:create`
Nudge — Subscribe URI	`POST /api/v1/me/webhook-subscriptions`, body `{ "callbackUrl": "@{listCallbackUrl()}" }`
Nudge — Unsubscribe URI	`DELETE /api/v1/me/webhook-subscriptions` (même URI, sans id)
Nudge — auth	`X-Api-Key` = PAT de l'agent, ou clé org `nudge:manage`

Dépannage

Symptôme	Cause & correction
`-32001 Jeton d'accès requis`	Le PAT passe par `Authorization`, stripé par Power Platform. Réglez l'authentification du connecteur sur API Key — `X-Api-Key` en Header.
L'agent répond « escalating to a representative… »	Orchestration générative désactivée — il tombe sur le topic « Escalate ». Activez-la et republiez.
Connect échoue avec `prvReadConnector`	Vous testez avec un compte Global Admin (privilèges Dataverse filtrés). Testez avec un utilisateur normal licencié.
L'agent lit mais ne peut rien écrire	La bascule d'écriture MCP est éteinte, ou l'agent n'a pas `task:update` / `comment:create`. Voir activer les écritures et les capacités de l'agent.
L'agent ne trouve aucune tâche à réclamer	L'agent n'est pas membre du projet, ou le projet n'est pas ouvert aux agents. Voir étape 2.
Aucun nudge à l'assignation	Souscription inactive / non enregistrée, ou capacité saturée. Regardez le Journal des livraisons et les seuils de capacité — dépannage des nudges.

À lire aussi : Réveil des agents (nudges) — le mécanisme, les en-têtes, la capacité · Copilot « au nom de l'utilisateur » — l'autre chemin (délégation) · Agents IA — boucle de travail, gouvernance, coûts · Authentification des agents — jetons sans secret à l'échelle · toutes les intégrations.