Sécurité et Protection des Données avec Microsoft Copilot

DESCRIPTION :

C’est l’article que tout DSI, RSSI et DPO attend. La question numéro 1 que j’entends depuis que Copilot est arrivé dans les discussions IT, c’est toujours la même : « Est-ce que nos données sont en sécurité ? ». Et derrière cette question simple se cache une multitude de sous-questions légitimes : est-ce que Copilot peut exposer des données confidentielles ? Est-ce que nos fichiers RH sont à l’abri ? Qu’est-ce qui se passe si un agent IA mal configuré accède à des ressources sensibles ? Et ce fameux Copilot Cowork qui peut agir de manière autonome, on peut lui faire confiance ?

Dans les articles précédents, nous avons déjà posé les bases de la confidentialité (article 1 : DPA, EU Data Boundary, Flex Routing, Anthropic) et de l’administration (article 4 : paramètres critiques, rôle AI Administrator). Cet article va beaucoup plus loin. On va parler de Microsoft Purview, des permissions SharePoint, de la sécurité des connecteurs, de la sécurité des identités d’agents dans Entra ID, et de la gouvernance de Copilot Cowork.

C’est un article dense, mais si vous ne devez en lire qu’un seul dans cette série avant de déployer Copilot en production, c’est celui-ci.

Cet article est le cinquième d’une série de 10 articles dédiés à Microsoft Copilot sur Infonovice.fr.

Voici le programme complet de la série :

Article 1 : Microsoft Copilot – Comprendre l’IA de Microsoft en 2026
Article 2 : Agent IA vs Assistant IA – Comprendre les nouveaux acteurs de l’IA en entreprise
Article 3 : Licences Microsoft Copilot en 2026 – Le guide complet pour s’y retrouver
Article 4 : Administrer Microsoft Copilot depuis le Microsoft 365 Admin Center
Article 5 (celui-ci) : Sécurité et Protection des Données avec Microsoft Copilot
Article 6 : Comprendre l’architecture des connecteurs Microsoft Copilot
Article 7 : Déployer des connecteurs Copilot préconfigurés – Guide pratique
Article 8 : Créer un connecteur Copilot custom et un serveur MCP
Article 9 : Créer et administrer des agents IA avec Copilot Studio et Agent Builder
Article 10 : Copilot Cowork, Researcher et les fonctionnalités avancées de Frontier
Article Bonus : Checklist de gouvernance Copilot pour l’admin d’un tenant M365

Bonne lecture !

Rappel : Le modèle de sécurité de base

Avant d’entrer dans les détails, rappelons les fondamentaux vus dans l’article 1. Microsoft 365 Copilot repose sur un modèle de sécurité qui s’articule autour de trois principes :

Vos données ne sont pas utilisées pour entraîner les modèles. C’est un engagement contractuel fort du DPA (Data Protection Addendum). Que ce soit via les modèles GPT d’OpenAI ou Claude d’Anthropic, vos prompts et réponses ne servent jamais à améliorer les modèles fondamentaux.

Copilot respecte les permissions existantes. Quand un utilisateur interroge Copilot, celui-ci ne peut accéder qu’aux données auxquelles cet utilisateur a déjà accès dans Microsoft 365. C’est le même modèle de permissions que pour Microsoft Search : si un fichier SharePoint est restreint par des ACL, Copilot ne le verra pas pour un utilisateur non autorisé.

Microsoft agit en tant que processeur de données. Au sens du RGPD, c’est votre organisation (le contrôleur) qui détermine les finalités du traitement. Microsoft (le processeur) traite les données selon vos instructions, dans le cadre contractuel du DPA et des Product Terms.

Microsoft Purview et Copilot

Microsoft Purview est la suite de conformité et de gouvernance des données de Microsoft 365. C’est votre allié principal pour sécuriser l’utilisation de Copilot en entreprise. Plusieurs composants de Purview interagissent directement avec Copilot.

Les labels de sensibilité (Sensitivity Labels)

Si vous utilisez déjà des labels de sensibilité dans votre organisation (et si ce n’est pas le cas, c’est le moment de s’y mettre), sachez que Copilot les respecte intégralement.

Concrètement :

Si un document Word porte un label « Confidentiel – Interne uniquement » avec des restrictions de copie/partage, Copilot hérite de ces restrictions quand il génère du contenu basé sur ce document.
Si un email est protégé par un label avec chiffrement IRM (Information Rights Management), Copilot ne pourra pas en extraire le contenu pour un utilisateur qui n’a pas les droits de déchiffrement.
Les labels suivent le contenu dans les réponses Copilot : si Copilot synthétise des informations provenant de plusieurs documents avec des labels différents, le label le plus restrictif est appliqué.

NB : Ces notions de labels et de chiffrement des documents peuvent vous sembler floues, surtout si vous n’avez jamais travaillé avec les technologies RMS (Rights Management Services) ou AIP (Azure Information Protection). Rassurez-vous : c’est tout à fait normal. Beaucoup de professionnels de l’informatique avec qui j’échange au quotidien n’en ont d’ailleurs jamais entendu parler.

Les ACL (Access Control Lists, ou listes de contrôle d’accès) traditionnelles permettent de gérer des droits de lecture ou d’écriture basiques, mais elles ne protègent plus réellement le document une fois qu’il est ouvert. Avec IRM, AIP ou RMS, on ajoute une couche de sécurité supplémentaire : le document peut être chiffré et certaines actions peuvent être bloquées, comme le copier-coller du contenu affiché, l’impression ou encore le transfert du document une fois ouvert.

Ce que vous devez faire :

Vérifiez que vos labels de sensibilité sont correctement configurés et que vos documents sensibles sont bien étiquetés. Copilot ne peut respecter que ce qui est en place.
Activez l’étiquetage automatique (auto-labeling) si ce n’est pas déjà fait, pour vous assurer que les documents ne restent pas sans label.
Auditez les labels existants pour vous assurer qu’ils reflètent votre politique de classification actuelle.

Les politiques DLP (Data Loss Prevention)

Les politiques de prévention de la perte de données s’appliquent aux interactions Copilot. Si vous avez des règles DLP qui empêchent le partage de numéros de carte bancaire, de numéros de sécurité sociale ou d’autres données sensibles, ces règles s’appliquent également quand Copilot génère des réponses.

Exemple : Si un utilisateur demande à Copilot « Résume les informations du client Jean Dupont », et que le résumé contiendrait un numéro de carte bancaire stocké dans un fichier Excel, la politique DLP peut bloquer ou censurer cette information dans la réponse.

Rétention et audit

Deux autres composants Purview essentiels pour Copilot :

Politiques de rétention : Vous pouvez définir des politiques de rétention spécifiques pour les interactions Copilot (prompts et réponses). Cela vous permet de conserver ces données pendant une durée définie pour des besoins de conformité, ou de les supprimer automatiquement après un certain délai.

Journaux d’audit : Toutes les interactions Copilot sont enregistrées dans les journaux d’audit Microsoft 365. Vous pouvez rechercher et analyser ces logs via le portail Purview pour des investigations de conformité ou des demandes eDiscovery.

eDiscovery : Les prompts et réponses Copilot sont inclus dans le périmètre eDiscovery. Si votre organisation fait l’objet d’une investigation légale, les interactions Copilot peuvent être recherchées, préservées et exportées comme toute autre donnée Microsoft 365.

NB : Les rôles pour accéder à ces fonctionnalités Purview sont séparés des rôles Copilot et Power Platform. Il faut des rôles dédiés : Compliance Admin, eDiscovery Manager, Audit Manager, etc. Ces rôles doivent être attribués dans le portail Purview ou dans Entra ID. Ni le rôle AI Administrator ni le rôle Power Platform Admin n’ont accès à ces fonctionnalités.

Le rôle crucial des permissions SharePoint et OneDrive

C’est le point que je considère comme le plus important de cet article, et paradoxalement, c’est celui qui est le moins technique. Il ne s’agit pas de configurer un outil complexe, mais de vérifier quelque chose de fondamental : vos permissions d’accès aux fichiers sont-elles correctement configurées ?

Le problème

Copilot ne montre que ce à quoi l’utilisateur a accès. C’est rassurant. Mais retournez la phrase : Copilot montre TOUT ce à quoi l’utilisateur a accès.

Beaucoup d’organisations ont, au fil des années, accumulé des permissions trop larges sur leurs sites SharePoint et leurs bibliothèques de documents. Des partages « Everyone except external users » sur des dossiers sensibles, des sites de projets jamais nettoyés après la fin du projet, des groupes Microsoft 365 avec des memberships trop larges…

Avant Copilot, ce n’était pas forcément un problème visible : les utilisateurs devaient activement chercher un document pour le trouver. Avec Copilot, la donne change. Copilot va proactivement chercher et synthétiser des informations pertinentes pour répondre à une question. Si un utilisateur du service marketing a accès (sans le savoir) à un site SharePoint RH contenant des grilles de salaires, et qu’il demande à Copilot « Quel est le salaire moyen dans notre entreprise ? », Copilot pourrait lui fournir la réponse en citant ces documents.

Ce que vous devez faire AVANT de déployer Copilot

Je ne saurais trop insister sur ce point : auditez vos permissions SharePoint AVANT de déployer Copilot. Pas après. Avant.

Voici une checklist :

1. Identifiez les sites SharePoint sensibles : RH, finance, direction, juridique, données personnelles. Vérifiez qui a accès à ces sites et resserrez les permissions si nécessaire.

2. Recherchez les partages trop larges : Identifiez les documents et dossiers partagés avec « Everyone » ou « Everyone except external users ». Identifiez les groupes SharePoint configuré en « Public » au niveau de leur paramètre de confidentialité. Restreignez-les à des groupes spécifiques.

3. Nettoyez les sites obsolètes : Les sites de projets terminés qui contiennent des données sensibles et dont les permissions n’ont jamais été revues sont un risque.

4. Utilisez SharePoint Advanced Management : Si vous avez une licence E5, cet outil permet d’auditer à grande échelle les permissions, les partages et les accès sensibles.

5. Mettez en place des revues de permissions régulières : C’est une bonne pratique générale, mais Copilot la rend indispensable.

NB : Ce travail de nettoyage des permissions est souvent le plus gros chantier d’un déploiement Copilot. C’est aussi le plus important pour la sécurité. Prévoyez-le dans votre planning de projet et impliquez les propriétaires de sites.

La sécurité des connecteurs Copilot

Les connecteurs Copilot (que nous détaillerons dans les articles 6 et 7) permettent d’ingérer des données externes dans Microsoft Graph ou de les interroger en temps réel. Ils introduisent un périmètre de données élargi que Copilot peut exploiter, ce qui nécessite une attention particulière en matière de sécurité.

Connecteurs synchronisés (Synced)

Les connecteurs synchronisés ingèrent des données externes dans Microsoft Graph. Les données sont indexées et stockées dans votre tenant.

Mécanismes de sécurité :

ACL (Access Control Lists) : Chaque élément ingéré via un connecteur synchronisé porte une ACL qui définit quels utilisateurs peuvent le voir. Copilot et Microsoft Search respectent ces ACL : un utilisateur ne verra dans les résultats que les éléments auxquels il a accès dans le système source.
Authentification : Les connecteurs synchronisés supportent plusieurs méthodes d’authentification pour se connecter à la source : authentification basique (login/mot de passe), OAuth 2.0 (ApplicationID/secret). OAuth 2.0 est recommandé quand il est disponible, car il évite le stockage d’identifiants en clair.
Consentement admin : Le déploiement d’un connecteur synchronisé nécessite la création d’une App Registration dans Entra ID avec des permissions Microsoft Graph spécifiques (ExternalItem.ReadWrite, ExternalConnection.ReadWrite). Un consentement admin est requis pour ces permissions.

NB : Les ACL des connecteurs reposent sur le système source. Si les permissions dans votre Confluence ou Salesforce sont mal configurées, ces mauvaises permissions seront répliquées dans l’index Graph et exploitées par Copilot. La responsabilité de la qualité des ACL vous incombe.

Connecteurs fédérés (Federated) — Preview

Les connecteurs fédérés fonctionnent différemment : les données ne sont jamais copiées dans Microsoft Graph. Elles restent dans le système source et sont récupérées en temps réel via le protocole MCP (Model Context Protocol) quand Copilot a besoin d’une information.

Mécanismes de sécurité :

OAuth 2.0 obligatoire : Les connecteurs fédérés utilisent exclusivement OAuth 2.0 pour l’authentification. Pas d’option d’authentification basique.
Données en lecture seule : Les connecteurs fédérés ne peuvent que lire des données. Ils ne peuvent pas écrire ou modifier quoi que ce soit dans le système source.
Pas de stockage dans Graph : Aucune donnée externe n’est stockée dans votre tenant. Les citations dans les réponses Copilot renvoient directement vers le contenu dans le système source.
Accès fédéré : Les permissions d’accès du système source sont respectées. L’utilisateur doit s’authentifier auprès du service externe (via le flow OAuth) pour que Copilot puisse récupérer ses données.

La sécurité des identités d’agents

Comme vu dans l’article 2, les agents créés dans Copilot Studio et Azure AI Foundry possèdent une identité propre dans Entra ID (App Registration ou la nouvelle Agent ID en Preview). Cette identité leur permet d’accéder à des ressources protégées via des permissions Microsoft Graph.

C’est un sujet de sécurité à part entière, car un agent mal sécurisé peut devenir un vecteur de fuite de données ou d’actions non autorisées.

Le parallèle avec les comptes de service classiques

Si vous avez lu mon article sur les comptes de services gMSA (Group Managed Service Accounts) sur ce blog, vous retrouverez ici la même logique. Un agent IA avec une identité Entra, c’est comme un compte de service classique dans Active Directory : il a besoin d’accéder à des ressources pour fonctionner, mais il faut contrôler strictement ce à quoi il a accès et avec quels privilèges.

La différence, c’est que les comptes de service classiques effectuaient des tâches prévisibles et déterministes (faire tourner un service Windows, exécuter un script planifié). Un agent IA, lui, peut avoir un comportement plus imprévisible puisqu’il prend des décisions basées sur un modèle de langage. C’est pourquoi la gouvernance de ses permissions est encore plus critique.

Permissions déléguées vs permissions Application

Quand vous attribuez des permissions Microsoft Graph à une identité d’agent dans Entra ID, vous avez deux options :

Permissions déléguées (Delegated) : L’agent agit au nom de l’utilisateur qui l’interroge. Il ne peut accéder qu’aux ressources auxquelles cet utilisateur a lui-même accès. C’est le modèle le plus sûr, car le périmètre d’action de l’agent est limité par les permissions de l’utilisateur.

Exemple : Un agent avec la permission déléguée Sites.Read.All ne pourra lire que les sites SharePoint auxquels l’utilisateur connecté a accès.
Consentement requis : AI Administrator peut accorder le consentement pour les permissions déléguées.

Permissions Application : L’agent agit en son propre nom, indépendamment de tout utilisateur. Il a potentiellement accès à TOUTES les ressources couvertes par la permission, sans restriction de contexte utilisateur. C’est le modèle le plus risqué.

Exemple : Un agent avec la permission Application Mail.ReadWrite peut lire et modifier les emails de TOUS les utilisateurs du tenant. Sans aucune restriction.
Consentement requis : Privileged Role Administrator ou Global Administrator uniquement. L’AI Administrator ne peut PAS accorder ce type de consentement, et c’est une mesure de sécurité délibérée.

Ma recommandation : Privilégiez toujours les permissions déléguées pour vos agents. N’utilisez les permissions Application que si c’est strictement nécessaire (agent de type « service » qui doit fonctionner sans contexte utilisateur), et dans ce cas, appliquez le principe du moindre privilège : attribuez uniquement les permissions minimales nécessaires au fonctionnement de l’agent.

Les bonnes pratiques pour les identités d’agents

Appliquez le principe du moindre privilège : Ne donnez à un agent que les permissions dont il a strictement besoin. Pas plus.
Identifiez un sponsor humain : Chaque agent doit avoir un responsable humain identifié qui est responsable de ses actions et de la revue régulière de ses permissions. C’est un principe de base d’Entra Agent ID.
Revues de permissions régulières : Comme pour les comptes de service classiques, planifiez des revues trimestrielles des permissions de vos agents.
Surveillez les agents à risque : Le rôle AI Administrator permet de voir les agents signalés par Entra Identity Protection for Agents. Consultez régulièrement cette vue.
Rotation des secrets : Si vos agents utilisent des secrets (client secrets) plutôt que des certificats, mettez en place une rotation régulière. Les certificats sont préférables aux secrets pour des raisons de sécurité.
Évitez les permissions Application en production : Sauf cas dûment justifié et documenté.

Entra Agent ID : Une couche de sécurité supplémentaire

La transition en cours vers Entra Agent ID (Preview) apporte des mécanismes de sécurité spécifiques aux agents qui n’existaient pas avec les App Registrations classiques :

Sponsor humain obligatoire : Chaque Agent ID est rattaché à un sponsor humain dans l’organisation.
Tokens just-in-time : Au lieu de secrets permanents, les Agent ID pourront demander des tokens d’accès à durée limitée et périmètre restreint.
Intégration Entra ID Governance : Les agents peuvent être soumis aux mêmes processus de gouvernance que les identités humaines : access packages, revues d’accès, politiques de cycle de vie.
Protocole A2A (Agent-to-Agent) : Quand des agents communiquent entre eux, le protocole A2A sécurise ces échanges avec des mécanismes d’authentification mutuelle.

NB : Entra Agent ID est en Preview et toutes ces fonctionnalités ne sont pas encore disponibles. Mais c’est la direction que prend Microsoft, et il est utile de la connaître pour anticiper vos choix d’architecture.

⚠️ Alerte gouvernance : Copilot Cowork

Ce sujet mérite une section dédiée, car Copilot Cowork représente un changement de paradigme en matière de risque.

Pourquoi Cowork est différent

Rappelons que Copilot Cowork est un agent autonome qui peut exécuter des tâches multi-étapes dans votre environnement Microsoft 365. Contrairement à Copilot Chat qui génère du texte, Cowork agit : il envoie des emails, crée des fichiers, modifie des documents, bloque des créneaux dans des calendriers…

Et surtout, Cowork agit sous l’identité de l’utilisateur qui lui a donné l’instruction. Les actions de Cowork sont indiscernables des actions manuelles de l’utilisateur dans les logs d’audit. Les politiques DLP, de rétention et d’audit s’appliquent normalement, car du point de vue du système, c’est l’utilisateur qui agit.

Le risque concret

Imaginez un utilisateur non formé qui écrit un prompt vague ou mal formulé à Cowork. Par exemple : « Fais le ménage dans mon OneDrive, supprime tout ce qui date de plus de 6 mois. » Cowork va planifier les étapes, identifier les fichiers, et commencer à les supprimer. Si l’utilisateur ne supervise pas attentivement la progression et ne vérifie pas chaque action avant de la valider, les dégâts peuvent être réels.

Autre exemple : « Envoie un email de relance à tous les clients qui n’ont pas payé leur facture. » Si les données de facturation accessibles via Microsoft Graph contiennent des erreurs ou des montants incorrects, Cowork enverra des emails avec des informations potentiellement fausses, au nom de l’utilisateur, à des clients réels.

Les garde-fous existants

Microsoft a intégré plusieurs mécanismes de protection :

Supervision visible : Cowork montre sa progression en temps réel et offre à l’utilisateur des points de contrôle pour valider ou corriger le plan avant qu’il ne soit exécuté.
Fenêtre d’annulation (Undo) : Selon les informations de la Wave 3, une fenêtre d’annulation configurable (par défaut 24 heures) permet de revenir en arrière sur certaines actions.
Politiques DLP : Les actions de Cowork sont soumises aux mêmes politiques DLP que les actions manuelles. Si une politique empêche l’envoi de données sensibles par email, Cowork sera bloqué de la même manière.
Journaux d’audit : Toutes les actions sont enregistrées dans les logs d’audit M365, traçables et analysables après coup.

Mes recommandations

1. Ne JAMAIS activer Frontier en tenant-wide. Scopez l’accès Frontier à un groupe de sécurité Entra dédié (ex : « Copilot-Frontier-PowerUsers ») contenant uniquement des utilisateurs formés et avertis des risques.

2. Formez vos utilisateurs Cowork. Avant de donner accès à Cowork à un utilisateur, assurez-vous qu’il comprend :

Que Cowork agit sous son identité (ses actions = ses responsabilités).
Qu’il faut toujours relire et valider le plan proposé par Cowork avant de le laisser s’exécuter.
Qu’il faut commencer par des tâches à faible risque pour se familiariser avec le comportement de l’outil.

Je recommande également de limiter l’accès à la fonctionnalité Cowork en configurant l’agent pour être accès qu’à un groupe d’utilisateurs identifiés. Dans le portail d’admin, allez dans le menu « Agents, puis sélectionnez « Tous les agents », rechercher l’agent « Cowork » et éditez l’onglet « Utilisateurs » pour sélectionner des utilisateurs ou groupes spécifiques. Grâce à cette option, vous êtes assuré d’autoriser l’accès à Cowork qu’aux utilisateurs formés et avertis.

3. Testez dans un environnement maîtrisé. Si possible, faites vos premiers tests Cowork avec des utilisateurs dont le périmètre d’accès aux données est limité (pas le CEO ou les Admins Globaux qui ont accès à tout le tenant).

4. Documentez votre politique d’accès à Cowork. Intégrez Cowork dans votre politique de sécurité SI : qui a le droit d’y accéder, dans quel cadre, quelles sont les actions interdites (ex : suppression en masse, envoi d’emails externes en masse).

5. Surveillez les logs d’audit. Mettez en place des alertes dans Purview pour détecter des actions inhabituelles (suppressions massives, envois d’emails en nombre) qui pourraient provenir d’un usage Cowork non maîtrisé.

NB : Rappelons que Cowork nécessite à la fois l’activation du programme Frontier et l’activation d’Anthropic comme sous-traitant. Pour les tenants EU, ces deux paramètres sont off par défaut. C’est une double couche de protection intentionnelle de la part de Microsoft.

La délégation et la visibilité : Les limites actuelles

C’est un point de frustration que je partage avec beaucoup d’administrateurs. La visibilité et la délégation de l’administration Copilot et des agents ne sont pas encore aussi matures qu’on le souhaiterait.

Ce qui est possible aujourd’hui

Au niveau M365 Admin Center :

L’AI Administrator a une vue globale sur les paramètres Copilot et les agents dans le portail M365 Admin Center.
L’AI Reader a une vue en lecture seule.

Au niveau Power Platform Admin Center :

Le Power Platform Admin a une vue sur tous les environnements, les crédits et les agents Copilot Studio.
Il n’existe pas encore de moyen natif de scoper cette visibilité par environnement. Un Power Platform Admin voit tout ou rien.

Au niveau Copilot Studio (par agent) :

Le rôle Analytics Viewer (notification MC1255508, disponible depuis le 31 mars 2026) est une avancée significative. Le propriétaire d’un agent peut désormais partager l’accès aux analytics d’un agent spécifique sans donner les droits d’édition.
Ce rôle est attribué depuis Copilot Studio via le bouton « Share agent », en cochant la case « Analyst » pour l’utilisateur concerné. Le système crée automatiquement un rôle Dataverse « Bot Viewer » scopé à cet agent.
L’utilisateur Analytics Viewer ne voit que les pages d’analytics. Toutes les autres pages (Knowledge, Topics, Tools, Publish, Settings) sont masquées ou désactivées.

NB : Il existe une limitation connue : un utilisateur ne peut pas être Analytics Viewer sur un agent et Editor sur un autre agent dans le même environnement. Si un utilisateur est déjà Editor sur un agent, il reçoit automatiquement le rôle Environment Maker pour l’environnement, ce qui lui donne plus de droits que souhaité.

Au niveau Viva Insights :

Le Copilot Dashboard est accessible aux senior leaders et managers avec la possibilité de déléguer l’accès à d’autres personnes.
L’Agent Dashboard (minimum 50 licences Copilot) offre une vue sur l’activité des agents.

Ce qui manque encore

Pas de scoping par environnement pour la vue consommation dans le PPAC (Power Plateform Admin Center). Un admin qui gère 5 environnements de production ne peut pas déléguer la vue d’un seul environnement à un responsable métier.
Pas de rôle « Copilot Studio Environment Admin » natif qui serait l’équivalent d’un admin scopé à un seul environnement.
Les rapports de consommation PPAC sont téléchargeables manuellement mais il n’y a pas d’export automatisé planifié ni d’API officielle stable pour les automatiser.

Solutions communautaires

Pour les organisations qui ont besoin d’une visibilité plus granulaire :

Le Copilot Studio Monitor (extension du CoE Kit, le « Center of Excellence » Kit de Microsoft) permet de remonter les données de configuration et d’activité des agents depuis Dataverse et de les visualiser dans Power BI.
Des dashboards Power BI custom peuvent être construits en se connectant directement aux tables Dataverse de chaque environnement pour agréger la consommation de crédits dans une vue unifiée multi-environnements.

Nous reparlerons de ces solutions de monitoring dans l’article 9 quand on abordera en détail l’administration des agents Copilot Studio.

Checklist sécurité avant déploiement Copilot

Pour conclure cet article, voici la checklist que je recommande de suivre avant de déployer Microsoft 365 Copilot en production dans votre organisation :

Données et permissions :

☐ Auditer les permissions SharePoint et OneDrive : identifier et corriger les partages trop larges (« Everyone », « Everyone except external users », « Public »).
☐ Vérifier que les sites sensibles (RH, finance, juridique, direction) ont des permissions restreintes aux personnes légitimes.
☐ Nettoyer les sites SharePoint obsolètes contenant des données sensibles.
☐ S’assurer que les labels de sensibilité sont déployés et correctement configurés.
☐ Activer l’auto-labeling pour les documents non encore étiquetés.

Conformité et gouvernance :

☐ Configurer des politiques DLP couvrant les interactions Copilot.
☐ Définir des politiques de rétention pour les prompts et réponses Copilot.
☐ Vérifier que les journaux d’audit sont activés et que l’équipe conformité y a accès.
☐ Documenter l’activation de Copilot dans votre registre RGPD / DPIA.

Paramètres Admin Center :

☐ Configurer le Flex Routing selon vos exigences de résidence des données (désactiver pour conformité stricte UE).
☐ Configurer les modèles Anthropic selon votre politique (off par défaut pour EU, activation raisonnée si nécessaire).
☐ Scoper le programme Frontier à un groupe restreint d’utilisateurs formés.
☐ Configurer les recherches web Bing (activer ou désactiver selon votre politique).

Agents :

☐ Définir une politique sur qui peut créer des agents (Agent Builder : tous les utilisateurs Copilot ; Copilot Studio : restreindre via le rôle Copilot Studio Authors dans le PPAC).
☐ Revue des permissions Graph des agents existants dans Entra ID.
☐ Identifier un sponsor humain pour chaque agent Copilot Studio.
☐ Configurer des limites de consommation par agent dans le PPAC.

Formation et communication :

☐ Former les utilisateurs pilotes sur les bonnes pratiques Copilot.
☐ Communiquer clairement sur ce que Copilot peut et ne peut pas faire.
☐ Définir un processus de feedback et de support pour les utilisateurs.
☐ Planifier une revue post-déploiement après 30 jours.

Conclusion

La sécurité de Microsoft Copilot repose sur un modèle solide (EDP, DPA, permissions héritées), mais il ne fonctionne correctement que si les fondations de votre tenant sont saines. Le point de vigilance numéro 1 est et reste la qualité des permissions SharePoint et OneDrive : Copilot ne fait qu’amplifier ce qui existe déjà, en bien comme en mal.

Les connecteurs élargissent le périmètre de données accessible à Copilot et nécessitent une attention particulière sur les ACL et les méthodes d’authentification. Les agents IA avec des identités Entra doivent être traités avec la même rigueur que des comptes de service : principe du moindre privilège, revue régulière, sponsor humain.

Enfin, Copilot Cowork représente un saut qualitatif en termes de capacités et de risques. Son accès doit être strictement contrôlé et réservé à des utilisateurs formés.

Dans le prochain article, on change de registre pour plonger dans l’architecture technique des connecteurs Microsoft Copilot : synchronisés vs fédérés, le protocole MCP, l’indexation sémantique dans Microsoft Graph, et le Graph Connector Agent pour les sources on-premises.

Liens utiles :

Enterprise Data Protection : https://learn.microsoft.com/en-us/copilot/microsoft-365/enterprise-data-protection
Data, Privacy and Security for Copilot : https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-privacy
Microsoft Purview with Copilot : https://learn.microsoft.com/en-us/purview/copilot-microsoft-365-purview
Entra Agent ID : https://learn.microsoft.com/en-us/entra/agent-id/identity-professional/microsoft-entra-agent-identities-for-ai-agents
Copilot Cowork : https://seanshares.com/what-is-microsoft-copilot-cowork-how-to-enable-it/

Article rédigé en Avril 2026. Les politiques de sécurité et les fonctionnalités de conformité évoluent régulièrement. Consultez la documentation Microsoft pour les dernières mises à jour.

Article précédent : [Administrer Microsoft Copilot depuis le Microsoft 365 Admin Center] Article suivant : [Comprendre l’architecture des connecteurs Microsoft Copilot]

Mots-clés suggérés pour WordPress : Copilot, Sécurité, Protection des données, Microsoft Purview, DLP, Sensitivity Labels, SharePoint, Permissions, RGPD, EU Data Boundary, Flex Routing, Anthropic, Connecteurs, Agents, Entra ID, Agent ID, Cowork, Gouvernance, Audit, eDiscovery, Conformité