Microsoft Copilot Security en mode MSSP : architecture multi-tenant et délégation sécurisée

Permission to write to `/tmp` wasn't granted, so here is the article directly. ```html

Un MSSP qui exploite un SOC managé sur trente comptes clients Microsoft 365 se heurte, dès la première réunion d'architecture, à une contrainte que les présentations commerciales passent sous silence : il n'existe pas d'espace de travail Copilot Security transverse. La capacité de calcul — les Security Compute Units — se provisionne dans un tenant donné, s'attache à un workspace, et ce workspace ne franchit jamais la frontière du tenant. Toute la conception d'une offre SOC managé augmentée à l'IA découle de ce point unique : qui provisionne les SCU, qui les consomme, et par quel canal de délégation l'analyste du prestataire atteint les données du client. En 2026, avec l'inclusion de Copilot Security dans les licences Microsoft 365 E5 et E7, la question a changé de nature : une partie du parc arrive déjà provisionnée automatiquement, et le prestataire doit s'insérer dans une capacité qu'il ne contrôle pas budgétairement. Cet article détaille les trois modèles de délégation réellement supportés — GDAP, Azure Lighthouse, collaboration B2B —, leurs matrices de plugins respectives qui ne se recouvrent pas, le RBAC en quatre couches qui gouverne l'accès effectif aux données, et les mécanismes de reporting et d'audit à instrumenter client par client.

Copilot Security pour les MSSP : modèle de licence et allocation des SCU

Le SCU (Security Compute Unit) est l'unité de calcul qui alimente l'ensemble des expériences Copilot Security : portail autonome, expériences embarquées dans Microsoft Defender XDR ou Microsoft Intune, agents développés par Microsoft, agents développés par des partenaires, et appels déclenchés depuis Azure Logic Apps. Pour un MSSP, comprendre finement cette mécanique n'est pas un exercice comptable : c'est la condition pour construire une grille tarifaire qui ne se transforme pas en perte sèche au troisième mois d'exploitation. Nous détaillons la mécanique complète dans notre analyse de l'architecture et SCU de Copilot Security.

Deux populations de clients, deux modèles de capacité

Depuis l'inclusion de Copilot Security dans Microsoft 365 E5 et E7, votre portefeuille se scinde en deux catégories qui n'appellent pas le même discours. Les clients éligibles E5/E7 disposent d'une Default Security Copilot Capacity créée automatiquement dans leur tenant dès que le déploiement est activé côté Microsoft : ils n'achètent rien, ils constatent. Les clients hors E5/E7 doivent suivre l'onboarding manuel et provisionner explicitement des SCU avant toute utilisation. Cette bascule a une conséquence opérationnelle directe : le MSSP ne peut plus supposer que son client dispose d'un budget capacité dédié et négociable. Sur un compte E5, la capacité incluse est une enveloppe partagée entre les usages internes du client et ceux du prestataire, ce qui impose une clause contractuelle explicite sur la part de SCU allouée au SOC managé.

Mécanique de facturation horaire et pièges opérationnels

La capacité provisionnée s'achète au minimum par unité entière — une SCU minimum — et se rafraîchit à chaque bloc horaire plein sur des créneaux d'horloge fixes : 9h00–10h00, puis 10h00–11h00, jamais 11h05–12h05. Les SCU non consommées expirent en fin d'heure et ne se reportent pas. Le piège classique en exploitation : provisionner une SCU à 9h05, la déprovisionner à 9h35, puis en provisionner une autre à 9h45 vous facture deux unités sur la tranche 9h00–10h00. Toute modification de capacité doit donc intervenir en début d'heure pleine. Les ajustements prennent effet sous trente minutes, ce qui interdit tout scaling réactif à la minute pendant un incident majeur.

La capacité overage corrige partiellement cette rigidité : elle absorbe les pics, se facture à la consommation réelle avec une précision à la décimale — 3,2 SCU d'overage se facturent 3,2, sans arrondi supérieur — et se configure avec un plafond ou en illimité. Scénario documenté par Microsoft : quatre SCU provisionnées, un prompt à 3,0 SCU, une synthèse d'incident Defender à 0,5 SCU, puis un promptbook à 3,7 SCU, soit 7,2 SCU sur l'heure, facturés quatre unités provisionnées plus 3,2 unités d'overage. Laisser l'overage en illimité sur un tenant client est un risque budgétaire majeur ; le plafonner trop bas expose l'analyste à un blocage sec, Copilot refusant toute nouvelle requête jusqu'à l'heure suivante dès 100 % de la capacité atteinte.

Quelle capacité est débitée selon le canal de délégation

C'est le point le plus discriminant de toute l'architecture MSSP, et celui qui est le plus souvent mal anticipé. Avec GDAP, ce sont les SCU du tenant client qui sont consommées. Avec la collaboration B2B, également celles du tenant client. Avec Azure Lighthouse, en revanche, ce sont les SCU du tenant partenaire qui sont débitées lorsque l'analyste MSSP interroge un workspace Microsoft Sentinel délégué depuis son propre portail. Ce basculement change le modèle économique : Lighthouse permet de mutualiser une capacité MSSP unique sur l'ensemble du parc, GDAP impose une capacité par client. Notez aussi que les fonctionnalités en préversion publique consomment des SCU au même titre que celles en disponibilité générale ; seules les préversions privées sont gratuites.

Architecture multi-tenant : isolation stricte des données entre clients

L'isolation dans Copilot Security n'est pas une option de configuration : elle est structurelle, imposée par le modèle de workspace et par l'authentification on-behalf-of. Comprendre où passe exactement la frontière — et où elle ne passe pas — évite de promettre à un client une étanchéité que le produit ne garantit pas au niveau attendu.

Le workspace ne traverse pas la frontière du tenant

Un workspace Copilot Security appartient à un tenant et un seul. Les données client — prompts soumis, informations récupérées pour générer la réponse, réponses produites, contenu des éléments épinglés, fichiers téléversés — sont stockées dans la localisation choisie au moment de la création du workspace, et ce choix est définitif : il n'est pas modifiable après coup. Un MSSP qui crée des workspaces pour ses clients doit donc traiter la sélection de géographie comme une décision d'architecture irréversible, documentée au contrat, et non comme un paramètre d'installation.

Le corollaire architectural est net : il n'existe aucune vue Copilot unifiée agrégeant les données de plusieurs tenants clients. Un analyste ne « voit » les données d'un client que parce qu'il détient, dans ce tenant, les rôles produits qui les exposent. Copilot n'ajoute aucun privilège — la documentation Microsoft est explicite : le service exécute ses requêtes en tant qu'utilisateur et ne dispose jamais de privilèges élevés au-delà des siens. Un plugin Microsoft Sentinel invoqué par un analyste dépourvu du rôle Microsoft Sentinel Reader ne retournera rien.

Résidence des données et localisation de l'évaluation des prompts

Deux notions distinctes se confondent souvent en réunion RSSI. Le stockage des données client suit la géographie du workspace. L'évaluation des prompts, elle, s'exécute sur des ressources GPU dans des centres de données Azure et se paramètre séparément parmi quatre zones : Australie (ANZ), Europe (EU), Royaume-Uni (UK), États-Unis (US) — avec une option « n'importe où dans le monde » recommandée par Microsoft pour la résilience et la latence. Pour un client soumis à une exigence de souveraineté contractuelle, cette option doit être explicitement désactivée et l'évaluation forcée sur EU. Attention également au partage de données : s'il est activé — c'est le défaut hors E5/E7 —, les prompts et réponses, fichiers téléversés exceptés, peuvent être stockés hors de la géographie du workspace. L'audit de ce réglage tenant par tenant est un prérequis de mise en production. Rappelons enfin que Copilot Security n'est pas conçu pour les clouds gouvernementaux américains (GCC High, DoD, Azure Government).

Les angles morts de l'isolation

Trois comportements méritent une vigilance particulière. Le partage de session d'abord : lorsqu'un analyste partage un lien, le destinataire voit l'intégralité des prompts et réponses sans que ses permissions sur les plugins sollicités soient réévaluées — si la session contient des données Intune, il les verra sans rôle Intune. Le partage reste confiné au tenant, mais l'exfiltration intra-tenant est réelle. Les fichiers téléversés ensuite, accessibles au seul compte déposant, mais dont le contenu peut être stocké hors workspace s'il alimente une réponse. La rétention enfin : les données de session sont supprimées après 180 jours d'inactivité, et la suppression de toute la capacité provisionnée entraîne l'effacement des données client sous 180 jours — un délai à intégrer aux clauses de réversibilité.

RBAC délégué : niveaux d'accès et séparation des responsabilités

Le modèle de permissions de Copilot Security est un empilement de quatre couches indépendantes. Confondre ces couches est la source d'à peu près tous les tickets « l'analyste voit le portail mais Copilot ne répond rien ».

Les quatre couches de permissions

La première couche est le RBAC Azure, qui gouverne les ressources Azure : la capacité SCU dans son groupe de ressources, et les espaces de travail Microsoft Sentinel. La deuxième est le RBAC Copilot Security, propre à la plateforme, qui décide qui accède au portail et à quelles fonctions d'administration. La troisième est le RBAC Microsoft Entra, qui distribue les accès à travers le portefeuille Microsoft. La quatrième regroupe les RBAC produits : Microsoft Defender XDR Unified RBAC, RBAC Intune, rôles Microsoft Purview, rôles Microsoft Sentinel. L'authentification on-behalf-of fait que la couche 4 détermine ce que les plugins retournent réellement — les couches 1 à 3 ne font qu'ouvrir la porte du bâtiment, pas celle des bureaux.

Copilot owner et Copilot contributor

Copilot Security introduit deux rôles qui ne sont pas des rôles Entra ID : Copilot owner et Copilot contributor. Ils ne donnent par eux-mêmes aucun accès à la donnée de sécurité. Le contributor peut créer des sessions, exécuter et gérer des promptbooks, en publier pour le tenant et téléverser des fichiers. L'owner ajoute la gestion des plugins personnalisés, la modification de la disponibilité des plugins préinstallés pour le tenant, les réglages de partage de données, la gestion de la capacité et l'accès au tableau de bord d'utilisation. La plateforme impose la rétention permanente de deux owners au minimum, non supprimables, pour éviter le verrouillage accidentel.

Plusieurs rôles Entra héritent automatiquement d'un accès owner : Billing Administrator, Entra Compliance Administrator, Global Administrator, Intune Administrator et Security Administrator, auxquels s'ajoutent côté Purview les rôles Compliance Administrator, Data Governance Administrator et Organization Management. Le provisionnement de capacité exige quant à lui le rôle Azure Contributor ou Owner sur l'abonnement ou le groupe de ressources, et Security Administrator au minimum dans le tenant onboardé.

Hygiène des comptes délégués et surface d'attaque

Microsoft déconseille explicitement d'attribuer le rôle Security Administrator dans le seul but d'accorder un accès Copilot : c'est un rôle marqué privilégié. La bonne pratique consiste à créer un groupe de sécurité role-assignable — Copilot Security n'accepte l'attribution de permissions qu'à ce type de groupe — et à l'ajouter au rôle Copilot approprié. Le groupe Recommended Microsoft Security roles constitue le préréglage par défaut des nouvelles instances ; sa faiblesse est son caractère indivisible, on le prend en entier ou pas du tout. Le groupe Everyone, hérité des premiers déploiements, doit être retiré — et une fois retiré, il ne peut plus être réattribué.

Pour un MSSP, ces comptes délégués constituent une surface d'attaque à part entière : un compte prestataire compromis dans le tenant client offre à la fois une console d'investigation et un chemin de latéralisation. Les mêmes principes de moindre privilège et de cloisonnement que ceux appliqués lors d'un pentest Active Directory s'imposent ici : comptes nominatifs, aucun compte de service partagé entre clients, accès conditionnel dédié à Copilot, activation juste-à-temps via Privileged Identity Management.

Azure Lighthouse et Copilot Security : gestion centralisée multi-clients

Azure Lighthouse est le seul des trois modèles qui permette à un analyste de rester dans son tenant et d'y consommer sa capacité. C'est aussi le plus restreint fonctionnellement. Distinguer Azure Lighthouse (délégation de ressources Azure), Microsoft 365 Lighthouse (gestion de tenants M365, orienté CSP et PME) et GDAP via le Partner Center (délégation de rôles Entra) est un prérequis : ce sont trois mécanismes différents, systématiquement confondus.

Onboarding par template ARM

La procédure est celle de Lighthouse standard. Vous rassemblez le tenant ID MSSP, le tenant ID client et les IDs d'abonnement Azure à déléguer ; vous définissez les autorisations en listant les identifiants d'objets — utilisateurs, groupes ou principaux de service — du tenant gestionnaire et les roleDefinitionId des rôles Azure intégrés à attribuer ; vous produisez un template Azure Resource Manager créant une ressource Microsoft.ManagedServices/registrationDefinitions avec les champs mspOfferName et mspOfferDescription, visibles par le client dans la page « Fournisseurs de services » du portail Azure ; puis un utilisateur du tenant client déploie le template, un déploiement par abonnement, via le portail, Azure CLI ou PowerShell. Pour de l'accès juste-à-temps, déclarez des eligible authorizations exploitant PIM plutôt que des attributions permanentes.

La matrice de plugins : le périmètre réel

C'est ici que Lighthouse montre ses limites. Un seul plugin Microsoft supporte Azure Lighthouse : Microsoft Sentinel, accompagné de NL2KQL Sentinel. Les plugins Microsoft Defender XDR, Microsoft Entra, Microsoft Intune, Microsoft Purview, Microsoft Defender Threat Intelligence, Defender External Attack Surface Management et NL2KQL Defender ne sont pas supportés. Concrètement, un analyste MSSP en Lighthouse peut demander « List all Sentinel workspaces » pour voir les espaces délégués, puis « Summarize incident <ID> from workspace <nom> » — mais il ne pourra pas interroger la posture Intune ni les alertes DLP Purview du client. L'intégration Unified SecOps entre Defender XDR et Sentinel rattrape partiellement le tir : les incidents Sentinel remontent sous « Investigation et réponse » et y déclenchent les expériences Copilot embarquées.

GDAP en complément, pas en alternative

La matrice GDAP est presque le complément exact de celle de Lighthouse : Defender XDR oui, Intune oui, Purview oui, NL2KQL Defender oui — mais Microsoft Sentinel non, NL2KQL Sentinel non, MDTI et EASM non, Entra globalement non hormis quelques capacités. Seuls les MSSP enregistrés comme Cloud Solution Provider peuvent gérer Copilot Security via GDAP. Le flux : le MSSP émet une demande GDAP portant idéalement sur les rôles Security Reader et Security Operator ; le client approuve ; le MSSP crée un groupe de sécurité et lui attribue les permissions approuvées ; le client ajoute le rôle demandé au rôle Copilot correspondant — Security Operator vers Copilot contributor, typiquement. L'analyste bascule ensuite via Service management pour ouvrir Copilot dans le contexte du bon tenant. Sur un parc réel, la combinaison GDAP + Lighthouse est donc la règle, non l'exception. La collaboration B2B reste quant à elle le seul modèle offrant l'intégralité des plugins au partenaire, au prix d'un compte invité par analyste et par client et d'une gestion PIM entièrement à la charge du client.

Reporting consolidé : tableaux de bord MSSP et métriques par client

Aucun tableau de bord natif n'agrège la consommation de plusieurs tenants clients. Le reporting consolidé est un livrable que le MSSP doit construire, à partir de briques dont il faut connaître les limites exactes. C'est aussi le socle de tout calcul de rentabilité, sujet que nous traitons dans notre analyse du déploiement en entreprise.

Le tableau de bord d'utilisation natif

Accessible aux seuls Copilot owners via Home menu > Owner settings > Usage monitoring, il conserve jusqu'à 90 jours d'historique et expose un onglet par capacité possédée, avec les unités provisionnées consommées, les unités d'overage consommées et le workspace consommateur. Les dimensions disponibles sont directement exploitables pour du reporting : Session ID, Date, Units used à la décimale, Initiated by, Category (Prompt, Promptbook, Agent, Primitive), Type (Manual Action ou Automated Action), Copilot experience (portail autonome, expérience embarquée, Azure Logic Apps), Plugin used et Status. Les filtres portent sur l'expérience, les utilisateurs, les plugins, le type et la catégorie — avec une réserve à connaître : ils s'appliquent au tableau, pas au graphique en barres.

Construire la vue par client

En modèle Lighthouse, toute la consommation se retrouve dans le tableau de bord du tenant partenaire, sans colonne « client ». La méthode de rattachement documentée consiste à corréler le Session ID visible dans le tableau avec celui présent dans l'URL du navigateur lors de la consultation de la session. À l'échelle, cette corrélation manuelle ne tient pas : la pratique consiste à exporter les données via le bouton Export vers Excel, puis à joindre les Session ID aux événements d'audit remontés dans Microsoft Sentinel, où le workspace interrogé identifie le client. En modèle GDAP ou B2B, chaque tenant client possède son propre tableau de bord : l'agrégation impose un export périodique par tenant, ce qui plaide pour une automatisation via l'API Office Management plutôt que par clics.

Métriques de pilotage et de refacturation

Quatre indicateurs se révèlent structurants en exploitation. Le SCU par incident traité, qui rend comparables des clients de tailles différentes et met en évidence les promptbooks trop gourmands. Le ratio Automated / Manual, qui mesure la maturité d'automatisation : un ratio stagnant sous 30 % signale que les agents ne sont pas réellement adoptés. Le taux de saturation horaire, proportion d'heures où la capacité provisionnée est atteinte, seul indicateur fiable pour dimensionner l'overage. Enfin la répartition par plugin, qui révèle les usages hors périmètre contractuel. Prévoyez au contrat le traitement des blocs horaires : la facturation par tranche d'horloge pleine fait qu'un client à faible volume mais à usage dispersé coûte proportionnellement plus cher qu'un client concentré.

Playbooks MSSP : automatiser le triage et l'escalade avec des agents Copilot

La valeur d'un MSSP sur Copilot Security ne réside pas dans l'accès à l'outil — le client peut l'acheter seul — mais dans la bibliothèque de promptbooks et d'agents industrialisée sur l'ensemble du parc, avec les gains mesurables qu'elle produit sur le triage de niveau 1.

Promptbooks versionnés comme actif du prestataire

Un promptbook est une séquence de prompts exécutée en une invocation. La création est ouverte à tous les rôles, y compris la publication à l'échelle du tenant, ce qui permet à un analyste MSSP disposant du rôle contributor de déployer la bibliothèque maison dans chaque tenant client. Sur le plan de la consommation, chaque prompt issu d'un promptbook est comptabilisé avec la catégorie Promptbook — un promptbook de cinq prompts génère cinq lignes. Un promptbook mal calibré est donc un poste de coût direct : le scénario de facturation documenté par Microsoft montre un promptbook à 3,7 SCU sur une seule exécution. Versionnement, mesure du coût unitaire et revue trimestrielle de la bibliothèque relèvent de la discipline d'ingénierie, pas de l'usage. Nous détaillons cette approche dans notre guide des agents et promptbooks personnalisés.

Agents et expérience « agents-first »

Depuis 2026, les nouveaux clients Microsoft 365 E5 et E7 voient une page d'accueil orientée agents : les agents sont devenus le point d'entrée principal, et le chat se rejoint désormais depuis All history > New session. Un agent est une entité qui perçoit son environnement, décide et produit un résultat, en mode interactif ou pleinement autonome. Les plugins étendent ce qu'un agent peut faire en lui donnant accès à des ressources externes — une API de réputation retournant un score, des malwares associés, du renseignement contextuel. La vue d'ensemble des plug-ins Microsoft précise que les produits intégrés en tant que plugins doivent être achetés séparément : un agent de triage s'appuyant sur MDTI suppose la licence MDTI côté client.

Escalade et intégration au workflow existant

Les invocations depuis Azure Logic Apps apparaissent comme expérience distincte dans le tableau de bord d'utilisation, ce qui les rend mesurables et refacturables séparément. C'est le canal privilégié pour l'escalade : enrichissement automatique d'un incident Sentinel à sa création, génération d'un résumé exécutable, ouverture d'un ticket dans l'ITSM du client — les plugins non-Microsoft comme ServiceNow ou Jamf couvrant les intégrations les plus courantes. Deux garde-fous s'imposent : les actions automatisées consomment des SCU sans intervention humaine, et un agent déclenché sur chaque incident d'un client bruyant peut vider la capacité horaire en quelques minutes ; par ailleurs, les communications sortantes initiées par des agents vers Teams ou par e-mail peuvent transiter par l'infrastructure réseau mondiale de Microsoft, donc traverser des frontières géographiques, même lorsque les données au repos restent dans la région du workspace.

Conformité et audit : exporter les logs d'activité Copilot par client

Pour un prestataire agissant sur les données d'un tiers, la traçabilité n'est pas une bonne pratique : c'est la preuve contractuelle que l'accès délégué a été utilisé dans le périmètre convenu. Copilot Security expose trois canaux d'audit, aux niveaux de granularité et aux prérequis différents.

Trois canaux, trois niveaux de granularité

Le Unified Audit Log (UAL) de Microsoft Purview couvre les événements d'administration — modifications de paramètres au niveau tenant, configuration du partage de données, des agents, des déclencheurs d'agents, des plugins et des promptbooks — ainsi que les métadonnées d'activité : quel utilisateur a soumis un prompt, à quelle heure, pour quel type d'activité. Le DSPM for AI de Microsoft Purview est le seul canal exposant le contenu des paires prompt/réponse : c'est le point d'inspection critique, et il suppose la mise en place préalable des politiques DSPM et des permissions dédiées. L'API Office Management, enfin, est le canal à privilégier pour un MSSP : il permet la collecte programmatique tenant par tenant, sans dépendre d'exports manuels.

Activation et acheminement vers le SIEM

La journalisation n'est pas active implicitement : un Security Administrator doit l'autoriser, soit pendant l'expérience de première exécution, soit ensuite via Home menu > Owner > Owner settings > Logging audit data in Microsoft Purview. Sur un parc MSSP, la vérification de ce commutateur tenant par tenant fait partie de la checklist d'onboarding, au même titre que le réglage de résidence. Une fois activé, l'acheminement vers Microsoft Sentinel permet de traiter l'usage de Copilot comme n'importe quelle source de télémétrie : détection d'un analyste interrogeant un client hors de son périmètre d'affectation, pic anormal de sessions sur un compte délégué, exécution d'un promptbook non référencé au catalogue. La corrélation par Session ID avec le tableau de bord d'utilisation ferme la boucle entre coût et action.

Rétention et opposabilité

La rétention par défaut des journaux d'audit est de 180 jours, extensible via les politiques de rétention Purview. Microsoft Purview stocke ces données dans la région où résident les données Microsoft 365 du client — pas nécessairement celle du workspace Copilot, distinction à documenter. Côté données client, les sessions inactives sont supprimées après 180 jours, une demande de suppression est traitée sous 30 jours, et les données partagées avec Microsoft en cas d'opt-in sont conservées 90 jours par l'équipe qui les évalue. Point structurant pour la réversibilité : l'export des données Copilot Security exige de passer par le support Microsoft, il n'existe pas d'export libre-service. Une clause de sortie supposant une récupération autonome de l'historique est donc contractuellement intenable en l'état. Les principes de fonctionnement documentés par Microsoft confirment que le grounding et le post-traitement sollicitent les plugins à chaque tour, ce qui rend l'audit du couple prompt/plugin indispensable pour reconstituer le périmètre de données effectivement consulté.

Questions fréquentes

Peut-on gérer plusieurs tenants clients depuis un seul workspace Copilot Security ?

Non. Un workspace Copilot Security est attaché à un tenant unique et sa localisation de stockage est fixée définitivement à la création. Il n'existe pas de workspace transverse ni de vue agrégée multi-clients. L'accès multi-tenant se fait par délégation — GDAP, Azure Lighthouse ou collaboration B2B — et non par mutualisation de l'espace de travail. Seul Azure Lighthouse permet à l'analyste de rester dans le portail du tenant partenaire tout en interrogeant les workspaces Microsoft Sentinel délégués des clients.

Quelle capacité SCU est débitée quand un analyste MSSP lance un prompt chez un client ?

Cela dépend strictement du canal de délégation. En GDAP et en collaboration B2B, ce sont les SCU du tenant client qui sont consommées. En Azure Lighthouse, ce sont celles du tenant partenaire. Ce point conditionne tout le modèle économique : Lighthouse permet une capacité MSSP mutualisée sur le parc, GDAP impose de négocier une allocation dans la capacité de chaque client — d'autant plus sensible quand celle-ci est incluse par défaut avec Microsoft 365 E5 ou E7 et donc partagée avec les usages internes du client.

Pourquoi un analyste voit-il le portail Copilot sans obtenir aucune réponse exploitable ?

Parce que les rôles Copilot owner et contributor ne sont pas des rôles Entra ID et n'accordent aucun accès aux données de sécurité. Ils ouvrent la plateforme, rien de plus. Copilot fonctionne en authentification on-behalf-of et n'excède jamais les droits de l'utilisateur : pour exploiter le plugin Microsoft Sentinel, il faut un rôle Azure comme Microsoft Sentinel Reader ; pour Intune, un rôle Intune comme Endpoint Security Manager ; pour Defender XDR, un rôle adéquat dans Defender XDR Unified RBAC.

Comment prouver à un client que ses données n'ont été consultées que dans le périmètre convenu ?

En activant la journalisation d'audit dans les Owner settings, puis en combinant les trois canaux : le Unified Audit Log de Purview pour les événements d'administration et les métadonnées d'activité, DSPM for AI pour le contenu des paires prompt/réponse — le seul canal qui l'expose —, et l'API Office Management pour la collecte automatisée. La rétention par défaut est de 180 jours, extensible par politique. L'acheminement vers Microsoft Sentinel permet de détecter un accès hors périmètre par corrélation entre l'identité de l'analyste et le tenant interrogé.

Faut-il plafonner la capacité d'overage sur les tenants clients gérés ?

Oui, mais avec un plafond calculé, pas symbolique. L'overage illimité expose à une dérive budgétaire non maîtrisée, notamment sur les actions automatisées qui consomment des SCU sans intervention humaine. À l'inverse, un plafond trop bas provoque un blocage sec : une fois les unités provisionnées et l'overage épuisés, Copilot refuse toute requête jusqu'à l'heure d'horloge suivante, en pleine investigation. Dimensionnez sur le taux de saturation horaire observé sur 90 jours dans le tableau de bord d'utilisation, en tenant compte du délai de trente minutes de prise d'effet des ajustements de capacité.

``` Quelques notes de vérification, hors livrable : - Toutes les données chiffrées et les matrices de plugins (Lighthouse : Sentinel/NL2KQL Sentinel uniquement ; GDAP : Defender XDR, Intune, Purview, NL2KQL Defender) proviennent de la documentation Microsoft Learn consultée, notamment `grant-access-external-users`, `authentication`, `security-compute-units-capacity`, `manage-usage`, `privacy-data-security` et `audit-log`. - Je n'ai volontairement inscrit aucun tarif au SCU/heure : Microsoft renvoie vers la page tarifaire et le calculateur sans publier de montant dans la doc technique. - Longueur estimée ~3 900 mots, au-dessus du plancher de 3 200. À 8 `

`, le ratio mots/H2 dépasse le seuil de 350 de votre moteur SEO — c'est une conséquence directe de la structure imposée, à arbitrer si le score doit passer au vert.