Une checklist opérationnelle pour cadrer les agents Copilot Studio avant leur création, leur pilote et leur généralisation : environnements, identités, DLP, connaissances, connecteurs, publication, audit et révocation.
Un agent Copilot Studio peut être construit rapidement par une équipe métier. Le déployer proprement dans une organisation est un sujet nettement plus large : il faut décider ce qu’il a le droit de consulter, d’exécuter, de révéler et de publier. La gouvernance ne doit donc pas arriver après le premier incident de données ou la première automatisation non maîtrisée.
Copilot Studio s’inscrit dans l’écosystème Power Platform et Microsoft 365. Microsoft y propose des contrôles de tenant et d’environnement, des stratégies de prévention de perte de données (DLP), des rôles, des mécanismes d’audit et des règles portant sur les connaissances et connecteurs. Ces briques ne remplacent toutefois pas une décision organisationnelle : elles permettent de l’appliquer.
Voici un document de travail à utiliser conjointement par la DSI, le RSSI, les administrateurs Power Platform et les propriétaires métiers. L’objectif n’est pas de ralentir les usages, mais de rendre explicites les conditions minimales d’un agent exploitable.
Traite chaque agent comme une application connectée à des données et à des actions métier. Son périmètre doit être limité par défaut, traçable et réversible, avant même d’être utile à grande échelle.
Avant la création : définir le périmètre et les garde-fous
La première décision concerne le cas d’usage, pas l’outil. Le sponsor métier doit décrire le besoin, les utilisateurs visés, les réponses attendues et les conséquences d’une mauvaise réponse. Un agent qui aide à retrouver une procédure interne n’a pas le même niveau de risque qu’un agent qui crée un ticket, consulte un CRM ou déclenche une action financière.
Checklist de cadrage
- Nommer un propriétaire métier responsable du contenu, de la pertinence des réponses et de la décision de mise hors service.
- Qualifier les données : publiques, internes, confidentielles, personnelles, réglementées ou soumises à un secret contractuel.
- Écrire les actions autorisées : informer, rechercher, résumer, créer un brouillon, ouvrir un ticket, modifier une donnée. Tout ce qui n’est pas explicitement admis reste hors périmètre.
- Choisir l’environnement : développement, test/pilote et production doivent être séparés. Évite de construire et tester un agent dans l’environnement de production par défaut.
- Définir les identités : qui peut créer, modifier, administrer, tester et publier ? Les rôles Power Platform doivent suivre le principe du moindre privilège.
- Fixer une durée de vie : date de revue, critère d’arrêt et responsable de l’archivage.
La question des sources de connaissances doit être traitée avec la même rigueur. Une URL accessible sur Internet n’est pas forcément une source admissible. Pour chaque domaine autorisé, documente le propriétaire, le niveau de confiance, la fréquence de mise à jour et les données qu’il est interdit d’y exposer. Établis une liste d’autorisation plutôt qu’une liste de blocage : les domaines inconnus restent exclus.
Question à valider : quelles URL, sites SharePoint, bases ou documents l’agent est-il autorisé à interroger, et qui peut ajouter une nouvelle source ?
Avant le pilote : verrouiller données, connecteurs et publication
Le pilote est le bon moment pour vérifier que le comportement réel correspond au périmètre approuvé. Il ne doit pas devenir une production déguisée ouverte à un groupe trop large. Sélectionne un panel d’utilisateurs identifiés, avec des scénarios de test positifs et négatifs.
Les stratégies DLP de Power Platform permettent de classer les connecteurs en groupes métier ou non métier et de les bloquer. Elles peuvent être appliquées à différents niveaux selon l’organisation. Le RSSI et l’administrateur de la plateforme doivent décider quels connecteurs sont admis dans l’environnement concerné. Cette décision doit couvrir aussi les connecteurs personnalisés, souvent oubliés lors des revues.
Questions à trancher avant l’ouverture du pilote
- Quels connecteurs sont interdits sans exception : messagerie personnelle, stockage grand public, réseaux sociaux, services non contractuellement approuvés ou connecteurs capables d’exporter des données sensibles ?
- Un agent peut-il appeler un flux Power Automate ? Si oui, quelles actions le flux peut-il effectuer et sous quelle identité ?
- Les utilisateurs voient-ils uniquement les contenus auxquels ils ont déjà accès ? Vérifie les permissions des sources, plutôt que de supposer que la configuration de l’agent les corrige.
- Qui peut publier sur Teams, un site web ou un canal interne ? La publication externe doit exiger une validation distincte.
- Quels messages doivent être refusés ou redirigés : demandes de données personnelles, instructions métiers à risque, requêtes hors périmètre ?
- Comment le pilote recueille-t-il les retours, erreurs factuelles, réponses dangereuses et tentatives de contournement ?
Teste en particulier les accès indirects. Un agent peut respecter ses instructions conversationnelles tout en révélant trop d’informations via une source trop large ou une action connectée. Les tests doivent donc inclure des requêtes visant à extraire des données, à contourner les consignes et à provoquer une action non autorisée.
Microsoft documente les contrôles de sécurité et de gouvernance de Copilot Studio, ainsi que les responsabilités partagées avec l’organisation cliente. Consulte aussi la FAQ de sécurité Copilot Studio avant de définir des exigences contractuelles ou de conformité.
Avant la généralisation : rendre l’exploitation vérifiable
La généralisation change l’échelle du risque : davantage d’utilisateurs, de conversations et de demandes de modification. Elle exige une procédure d’exploitation, pas seulement l’accord donné à un pilote concluant.
Checklist de mise en production
- Publication : liste nominative ou groupe autorisé à publier, approbation de mise en production et inventaire des canaux actifs.
- Journalisation : identifie où consulter les événements d’administration et d’activité pertinents, notamment dans les capacités d’audit Microsoft 365/Purview et les consoles Power Platform selon les services activés.
- Surveillance : définis des seuils de revue : hausse d’erreurs, ajout de connecteur, changement de source, volume inhabituel ou publication sur un nouveau canal.
- Gestion du changement : une modification de connaissances, de connecteurs, d’instructions ou de canal doit avoir un propriétaire, une trace et, pour les changements sensibles, une nouvelle validation.
- Révocation : documente comment retirer un utilisateur, désactiver un connecteur, dépublier un canal, supprimer les droits d’un maker et arrêter l’agent.
- Continuité : prévois un contact de remplacement et une procédure si le propriétaire métier quitte l’entreprise.
Ne réduis pas l’audit à une obligation de conformité. Les journaux servent à enquêter après un incident, mais aussi à comprendre pourquoi l’agent a produit une réponse ou déclenché une action. Vérifie régulièrement que leur accès est limité aux personnes habilitées et que leur conservation répond aux règles internes applicables.
RACI minimal : qui décide, qui exécute, qui contrôle ?
Le tableau suivant est volontairement compact. Adapte-le à ta structure, mais ne laisse jamais la publication et les données sans responsable explicite.
Activité Métier DSI/Power Platform RSSI DPO/Conformité Cas d’usage et contenu A/R C C C Environnement et rôles C A/R C I DLP et connecteurs C R A C Sources de connaissances A/R C C C Validation du pilote A R C I Publication en production A R C I Audit, incidents et révocation C R A C Revue périodique et décommissionnement A/R R C I A = accountable (redevable) | R = responsible (réalise) | C = consulté | I = informé
Dans une petite structure, une même personne peut cumuler plusieurs rôles. Ce cumul ne doit pas supprimer la revue indépendante des changements à risque : publication externe, accès à des données sensibles, connecteurs d’écriture ou automatisations ayant un effet financier.
Une règle simple pour démarrer sans bloquer les équipes
Commence avec un environnement de pilote isolé, une liste courte de sources approuvées, des connecteurs limités et une publication réservée à un groupe d’administrateurs. Élargis ensuite un seul paramètre à la fois : un nouveau public, une nouvelle source ou une action supplémentaire. Après chaque élargissement, relis les journaux, les retours utilisateurs et les résultats de tests de sécurité.
La gouvernance utile se mesure à sa capacité à répondre rapidement à quatre questions : qui a publié cet agent, quelles données peut-il atteindre, quelles actions peut-il lancer et comment coupe-t-on l’accès maintenant ? Si l’équipe ne peut pas répondre en quelques minutes, le déploiement n’est pas encore prêt à être généralisé.