Un agent Copilot est un assistant virtuel basé sur l’IA générative, créé via Microsoft Copilot Studio, capable de dialoguer avec des utilisateurs et d’agir sur des données ou applications connectées. En entreprise, un agent peut répondre aux questions du support (clients, collaborateurs), automatiser des contrôles (conformité, qualité), qualifier des demandes entrantes ou orchestrer des processus métier complexes. Aujourd’hui, de nombreuses organisations disposent d’un inventaire de leurs agents : elles savent combien d’agents existent. Mais peu savent ce que ces agents peuvent réellement faire — quels connecteurs ils utilisent, quelles données ils consultent, quelles actions ils déclenchent. Cet article fournit une checklist pragmatique pour passer de l’inventaire à la maîtrise qualitative de vos agents Copilot.
1. Ce qu’on voit… et ce qu’on ne voit pas
Les outils d’inventaire standard montrent le quoi, pas le comment.
Plusieurs inventaires et outils existent nativement (PPAC Inventory, MAC Agent Registry, Agent 365, CoE Starter Kit), mais aucun ne fournit aujourd’hui une vue complète de la configuration des agents. Les questions de gouvernance essentielles restent sans réponse avec ces outils seuls : quels agents utilisent la fonctionnalité Computer Use ? Lesquels peuvent opérer de manière anonyme ? Lesquels sont connectés à un service externe donné ?
Les données de configuration existent dans Dataverse, mais sont complexes à exploiter.
Chaque agent Copilot Studio stocke sa configuration en base de données. La table « Copilot (bot) » contient les informations générales de l’agent. La table « Copilot component (botcomponent) » contient le détail de ses composants : connaissances, actions, connecteurs, prompts. Le problème : les détails critiques sont encapsulés dans une colonne YAML. Sans extraction et transformation spécifiques, ces données ne sont pas lisibles directement.
Exemple d’angle mort concret. Un agent de test, non publié, est configuré avec un connecteur vers l’Active Directory et des droits de gestion d’utilisateurs. Tant qu’il n’est pas publié, pas de risque immédiat. Mais si un maker le publie par erreur, l’agent peut potentiellement créer ou modifier des comptes — avec les droits d’un administrateur. Ce type de situation justifie à lui seul un audit régulier.
2. Les 5 dimensions à auditer systématiquement
| Dimension | Ce qu’il faut vérifier | Risque si ignoré |
| Identité & périmètre | Nom explicite, environnement (dev / test / prod), sponsor métier identifié. | Agents orphelins sans responsable, doublons non détectés. |
| Connexions & comptes | Type de connexion utilisé : session de l’utilisateur final ou compte du créateur (maker/admin). Microsoft permet aux makers de configurer les outils pour utiliser les identifiants de l’utilisateur par défaut. | Un agent utilisant le compte d’un admin dispose de privilèges excessifs et échappe aux contrôles de droits individuels. |
| Connecteurs appelés | Liste exhaustive des connecteurs (Outlook, SharePoint, SQL, API custom…). Mode d’authentification. | Accès non autorisé à des systèmes sensibles (messagerie, bases de production, ERP). |
| Sources de connaissance | Documents SharePoint, fichiers indexés, sites web. L’IA génère ses réponses à partir de ces sources. | Données confidentielles ou obsolètes intégrées au corpus, réponses inexactes ou fuites d’information. |
| Capacités avancées | Actions automatisées (Power Automate, HTTP), serveurs MCP, prompts personnalisés, sous-agents, recherche web. | Un agent qui déclenche des actions en production sans supervision, ou qui orchestre d’autres agents sans traçabilité. |
| Publication & audience | Canaux de publication : Teams, Microsoft 365 Copilot, site web externe. Audience réelle. Un agent publié sur Teams est potentiellement accessible à toute l’organisation. | Exposition externe d’un agent prévu pour un usage interne, audience non maîtrisée. |
4. Les 5 signaux d’alerte les plus fréquents
1. Agent sans sponsor identifié. Personne ne pourra le maintenir, le corriger ou le désactiver en cas de problème.
2. Agent utilisant la connexion du maker avec un compte à privilèges élevés. Actions exécutées avec des droits administrateur, sans traçabilité individuelle.
3. Agent connecté à un système critique (messagerie, ERP, base de production) sans que l’équipe sécurité en soit informée.
4. Agent publié sur un canal externe (site web, Teams large audience) sans revue de son corpus de connaissances — risque de fuite d’information.
5. Agent inactif en production : non utilisé depuis plusieurs mois, mais avec des connexions et des droits toujours actifs. Une dette de gouvernance invisible.
5. L’inventaire natif devient un socle standard de la Power Platform.
Avec la Power Platform Release Wave 1 2026, Microsoft a profondément renforcé les capacités natives d’inventaire et de gouvernance des agents. Les fonctionnalités d’inventaire ne reposent plus sur des briques additionnelles, mais sont désormais intégrées directement dans le Power Platform Admin Center et dans Agent 365.
Agent 365 centralise la visibilité sur les agents Copilot.
Agent 365 fournit une vue unifiée des agents déployés dans le tenant : environnements, statut de publication, capacités activées (IA générative, recherche web, actions, MCP), et surfaces d’exposition (Microsoft 365, Teams, web). Cette vision transverse permet enfin de dépasser une simple liste d’agents pour comprendre où et comment l’IA est réellement utilisée.
Les contrôles de gouvernance deviennent natifs.
Les administrateurs disposent désormais de contrôles intégrés pour :
- identifier les agents utilisant des capacités sensibles (connecteurs critiques, actions automatisées, serveurs MCP),
- appliquer des politiques de prévention des pertes de données (DLP) adaptées aux agents,
- surveiller l’évolution des usages et de la consommation.
Ces contrôles permettent de détecter rapidement les écarts par rapport aux standards définis par le Centre d’Excellence.
Dataverse reste la source de vérité.
Même avec ces avancées, la configuration détaillée des agents (instructions, composants, connexions, sources de connaissance) demeure stockée dans Dataverse, au sein des tables *Copilot (bot)* et *Copilot component (botcomponent)*. L’exploitation de ces données nécessite toujours un travail d’extraction et de structuration pour obtenir une vision réellement exploitable au niveau gouvernance.
6. La gouvernance des agents Copilot : un sujet à prendre au plus haut niveau de l’entreprise.
Une gouvernance efficace ne consiste pas à multiplier les validations ou à centraliser toutes les décisions. Elle repose sur un principe simple : savoir précisément ce que vos agents peuvent faire, avant de chercher à les contrôler. Tant que cette compréhension fait défaut, l’organisation navigue à vue — et les décisions deviennent défensives, tardives ou excessivement restrictives.
En s’appuyant sur les capacités désormais intégrées de la Power Platform et d’Agent 365, complétées par une lecture structurée des données de configuration stockées dans Dataverse, il devient possible de passer :
- d’une logique de suspicion à une logique de pilotage,
- d’un inventaire passif à une gouvernance active,
- d’une innovation perçue comme risquée à une innovation maîtrisée et assumée.
C’est cette approche qui permet aux directions IT et digitales de jouer pleinement leur rôle : sécuriser le cadre, sans étouffer les usages ; accompagner la montée en charge, sans perdre le contrôle ; et créer les conditions pour que l’IA devienne un atout durable pour l’entreprise, plutôt qu’un sujet d’inquiétude.
→ Vous souhaitez comprendre comment l’IA Copilot peut accélérer votre productivité dans l’écosystème Microsoft ?
Dynagile s’appuie sur une culture de l’innovation et une curiosité partagée par l’ensemble de ses consultants, techniques comme fonctionnels. Chaque jour, nous développons en interne et avec nos clients des nouveaux cas d’usage pour faire de l’IA un allié du quotidien.
