Architecture de Microsoft Copilot Security : SCU, plugins et flux de données décryptés

Je n'ai pas les permissions d'écriture sur `/tmp` dans cette session, donc voici directement le HTML (les sources Microsoft Learn ont été vérifiées : docs SCU/capacité, confidentialité, authentification, provisionnement automatique E5/E7, mises à jour juin–août 2026). ```html

Trois ans après la disponibilité générale de Microsoft Security Copilot, la question posée en comité de sécurité n'est plus « faut-il y aller ? » mais « qu'est-ce qui sort exactement de notre tenant quand un analyste tape une invite ? ». En 2026, la donne a changé : l'inclusion de Security Copilot dans les licences Microsoft 365 E5 et E7 a fait basculer des milliers de tenants français en provisionnement automatique, souvent sans que le RSSI n'ait validé l'emplacement de stockage des données client, l'emplacement d'évaluation des invites ou les rôles hérités par défaut. Dans le même temps, la directive NIS2 impose de documenter les traitements de sécurité sous-traités, et le RGPD ne fait aucune exception pour l'IA générative appliquée aux journaux d'authentification. Comprendre l'architecture réelle du produit — la mécanique du grounding, la nature des Security Compute Units, le modèle d'autorisation on-behalf-of, les frontières géographiques du traitement — n'est plus un exercice d'architecte curieux : c'est le prérequis pour signer une analyse d'impact et pour éviter une facture Azure qui triple en un trimestre. Cet article décrypte chacune de ces couches, avec les paramètres exacts et les arbitrages observés en production.

Vue d'ensemble de l'architecture : où vit Copilot Security dans l'écosystème Microsoft

Security Copilot n'est pas un produit de sécurité au sens classique : il ne collecte rien, ne détecte rien et ne stocke aucune télémétrie brute. C'est une couche d'orchestration posée au-dessus du portefeuille Microsoft Security, qui compose des réponses en langage naturel à partir de données qu'elle va chercher, à la demande, dans les produits que vous possédez déjà. Cette distinction est structurante : sans Microsoft Defender XDR, Microsoft Sentinel, Microsoft Intune, Microsoft Purview ou Microsoft Entra ID correctement déployés et licenciés, Copilot n'a littéralement rien à raconter. La documentation officielle de Microsoft Security Copilot sur Microsoft Learn le formule sans détour : les produits qui s'intègrent en tant que plug-ins doivent être achetés séparément.

Le plan d'orchestration : grounding, inférence, post-traitement

Le cycle de traitement d'une invite comporte quatre temps, et c'est là que se joue toute l'architecture. Premièrement, l'invite utilisateur — saisie dans le portail autonome ou déclenchée depuis une expérience embarquée — est transmise au service Security Copilot. Deuxièmement, le service applique un prétraitement dit « grounding » : il enrichit et spécifie l'invite en interrogeant les plug-ins pertinents, afin que le modèle de langage reçoive un contexte organisationnel et non une question abstraite. Troisièmement, l'invite ainsi augmentée part vers le modèle de langage, évalué sur des clusters GPU dans des centres de données Azure. Quatrièmement, la réponse du modèle subit un post-traitement qui peut lui-même rappeler des plug-ins pour compléter, vérifier ou formater le résultat.

Conséquence opérationnelle directe : une seule invite utilisateur peut générer plusieurs appels d'inférence et plusieurs appels d'API vers vos produits de sécurité. C'est le mécanisme fondamental qui explique pourquoi la consommation de calcul n'est ni linéaire ni prévisible à l'invite près, et pourquoi les modèles de coût bâtis sur « nombre d'analystes × nombre de questions par jour » se révèlent systématiquement faux.

Expérience autonome et expériences embarquées

Deux surfaces d'exposition coexistent. L'expérience autonome est le portail securitycopilot.microsoft.com, immersif, avec sessions, promptbooks, agents et gestion des plug-ins. Les expériences embarquées sont les points d'entrée Copilot dans les portails Defender, Entra, Intune et Purview : résumé d'incident, analyse de script, explication de requête KQL, synthèse de risque d'identité. À cela s'ajoute une troisième voie souvent oubliée dans les schémas d'architecture : Azure Logic Apps, qui permet d'invoquer Copilot depuis un workflow automatisé, sans interaction humaine. Les trois surfaces consomment la même capacité et remontent dans le même tableau de bord d'utilisation, avec une colonne « Expérience Copilot » qui permet de les distinguer.

L'espace de travail : l'objet d'architecture que tout le monde oublie

L'unité logique centrale n'est ni le tenant ni la capacité, mais l'espace de travail (workspace). Un espace de travail définit trois choses et trois seulement : l'emplacement de stockage des données client, la capacité de calcul qui l'alimente, et la liste des propriétaires et contributeurs Security Copilot. Point critique pour toute conception : l'emplacement de stockage d'un espace de travail est immuable après création. Vous pouvez créer plusieurs espaces de travail avec des géographies différentes, mais vous ne pouvez pas déplacer un espace de travail existant. Les expériences embarquées dans Defender, Entra, Purview et Intune utilisent systématiquement l'espace de travail par défaut — et si votre tenant en possède plusieurs, c'est le plus ancien qui hérite de ce statut. Une erreur de géographie sur le premier espace de travail créé se paie donc par une recréation complète.

Les Security Compute Units : modèle de consommation, tarification et optimisation

La SCU est l'abstraction de facturation et de capacité du produit. Elle représente la ressource de calcul nécessaire pour exécuter les charges de travail Security Copilot : portail autonome, expériences embarquées, agents développés par Microsoft, agents développés par des partenaires, et toute fonctionnalité additionnelle. Elle n'est pas une unité de jeton, ni une unité de requête, ni une licence utilisateur. C'est un débit horaire.

Capacité provisionnée : un débit horaire non capitalisable

La capacité provisionnée est l'allocation de référence que vous configurez, avec un minimum d'une SCU. Le mécanisme de renouvellement est le point que 90 % des équipes comprennent de travers : la capacité est réactualisée par heures de facturation pleines et alignées sur l'horloge — 9h00–10h00, puis 10h00–11h00 — et non sur des fenêtres glissantes de soixante minutes. Les SCU non consommées dans l'heure expirent et ne se reportent pas. Trois SCU provisionnées, c'est trois SCU disponibles entre 9h00 et 10h00, puis trois nouvelles entre 10h00 et 11h00, sans cumul.

Deuxième subtilité coûteuse : toute modification de provisionnement dans une heure donnée est facturée à l'heure pleine. L'exemple donné par Microsoft est explicite — provisionner une SCU à 9h05, la déprovisionner à 9h35, puis en provisionner une autre à 9h45 vous fait facturer deux unités sur la tranche 9h00–10h00. La règle d'or opérationnelle en découle : tout changement de capacité se fait au début de l'heure. Les ajustements prennent par ailleurs jusqu'à 30 minutes pour être effectifs, ce qui interdit toute forme de scaling réactif à la minute.

Capacité de dépassement : l'amortisseur, facturé à la décimale

La capacité de dépassement (overage) est la soupape. Elle se consomme à l'usage, uniquement lorsque la capacité provisionnée est épuisée, et se configure soit avec un plafond maximal, soit en illimité. Contrairement au provisionné, elle est facturée à la décimale près des unités réellement consommées, sans arrondi à l'entier supérieur. Le scénario de référence documenté : une organisation provisionne 4 SCU avec un plafond de dépassement à 6. Une heure donnée, un analyste consomme 3,0 SCU sur une invite complexe, 0,5 SCU sur un résumé d'incident dans Defender, puis 3,7 SCU sur un promptbook — total 7,2 SCU. La facturation sera de 4 SCU provisionnées plus 3,2 SCU de dépassement.

Retenez l'ordre de grandeur de ce scénario officiel : une seule invite peut coûter 3 SCU, un promptbook 3,7 SCU. La capacité provisionnée minimale d'une SCU ne suffit donc même pas à absorber une invite d'investigation moyennement complexe. Toute simulation budgétaire construite sur « une invite = une fraction de SCU » est fausse d'un ordre de grandeur.

Optimisation : les leviers qui fonctionnent réellement

Le premier levier est le choix illimité vs plafonné sur le dépassement. Le plafonné protège le budget mais dégrade le service : lorsque provisionné et dépassement sont tous deux épuisés à 100 %, les analystes reçoivent un message d'erreur et ne peuvent plus soumettre d'invites jusqu'à l'heure suivante. En pleine gestion d'incident majeur, c'est un risque opérationnel qu'il faut arbitrer explicitement avec la direction, pas subir. Le compromis pragmatique consiste à plafonner haut plutôt qu'à laisser illimité, et à câbler une alerte de coût Azure sur la ressource de capacité.

Le deuxième levier est le profilage par catégorie. Le tableau de bord de surveillance de l'utilisation, accessible aux propriétaires Copilot via Menu Accueil > Paramètres du propriétaire > Surveillance de l'utilisation, conserve 90 jours d'historique et ventile chaque session par catégorie — Invite, Promptbook, Agent, Primitif — par type (action manuelle ou automatisée), par plug-in utilisé et par initiateur. Exportez ces données en Excel et croisez-les : dans la majorité des tenants audités, la consommation est dominée par les actions automatisées (résumés d'incidents systématiques, agents planifiés, workflows Logic Apps), pas par les analystes. Un résumé d'incident automatique sur une file d'alertes bruyante est le premier poste de gaspillage à traiter, avant toute discussion sur le comportement des utilisateurs.

Le troisième levier est temporel : provisionner au plus juste la nuit et le week-end si votre SOC n'est pas en 24/7, et laisser le dépassement absorber les astreintes. Sur la base du tarif public de référence de 4 USD par SCU et par heure, une SCU provisionnée en continu représente environ 2 900 USD par mois (730 heures) : passer de 4 SCU permanentes à 4 SCU en heures ouvrées plus dépassement divise la facture de base par trois. Vérifiez toujours le tarif applicable à votre contrat sur la calculatrice de prix Azure avant de figer un budget. Ces arbitrages de dimensionnement sont détaillés dans notre analyse du déploiement de Copilot Security en entreprise.

L'inclusion Microsoft 365 E5 et E7 : un changement d'architecture, pas seulement de facture

C'est l'évolution majeure du cycle 2026, et elle est mal comprise. Pour les tenants Microsoft 365 E5 et E7 éligibles et activés, Microsoft provisionne automatiquement Security Copilot : création d'une capacité virtuelle par défaut, création d'un espace de travail par défaut, affectation des paramètres d'espace de travail, de l'emplacement d'évaluation des invites, de l'accès aux données Microsoft 365 et des rôles par défaut. Aucune action administrateur n'est requise — et c'est précisément le problème du point de vue de la gouvernance.

Les valeurs présélectionnées méritent une revue immédiate. L'emplacement de stockage des données client est aligné sur la géographie Microsoft Entra du tenant, sauf si un remplacement Microsoft 365 existe (Preferred Data Location, programmes Go Local, module complémentaire Advanced Data Residency), auquel cas ce remplacement est mappé vers une géographie supportée par Security Copilot. L'accès aux données des services Microsoft 365 est activé (ON) par défaut. En revanche — et c'est la bonne nouvelle — les deux préférences de partage de données client sont positionnées sur Désactivé par défaut en provisionnement automatique, à l'inverse du provisionnement classique où le partage de données est activé par défaut.

Autre différence structurante : en provisionnement automatique, l'héritage de rôles est plus large. Administrateur général, Administrateur de sécurité, Administrateur de l'accès conditionnel, Administrateur Intune, le bundle Conformité (Administrateur de conformité Microsoft Entra, Administration de conformité Purview, Gestion de l'organisation Purview) et Administrateur Gouvernance des données Purview héritent tous du rôle propriétaire Security Copilot. Si votre tenant compte trente titulaires de ces rôles, vous avez trente propriétaires Copilot capables de modifier les paramètres de partage de données. La première action post-activation consiste à auditer la page Attribution de rôle et à réduire cet héritage.

Système de plugins : first-party, third-party et personnalisés

Un plug-in est une collection d'outils — également appelés compétences (skills) — que Copilot peut invoquer pendant le grounding ou le post-traitement. La documentation officielle des plug-ins Security Copilot définit un outil comme une ressource accessible en dehors des instructions de l'agent et du LLM. C'est le vrai plan de données du produit : sans plug-in actif, aucune donnée organisationnelle n'atteint le modèle.

Plug-ins Microsoft

Préinstallés et activés par défaut, ils couvrent Microsoft Defender XDR, Microsoft Sentinel, Microsoft Entra, Microsoft Intune, Microsoft Purview, Microsoft Defender Threat Intelligence, Microsoft Defender External Attack Surface Management et les sources faisant autorité (profils Intel, rapports d'analyse des menaces, publications de divulgation de vulnérabilités). Ils utilisent le flux d'authentification on-behalf-of : Copilot accède aux données avec l'identité et les autorisations de l'utilisateur connecté, jamais avec des privilèges élevés. Certains plug-ins préinstallés — Microsoft Sentinel, Azure AI Search — exigent néanmoins une configuration explicite (identifiant d'abonnement, groupe de ressources, nom d'espace de travail) et se paramètrent par utilisateur, ce qui est une source classique de tickets « Copilot ne voit pas mes incidents ».

Plug-ins non-Microsoft

ServiceNow, Jamf et un catalogue partenaire en croissance. Ils apportent le contexte ITSM, la conformité des terminaux ou l'enrichissement de réputation. Deux règles de gouvernance s'imposent : ces produits doivent être achetés séparément, et leur activation ouvre un canal sortant vers un tiers qui doit figurer dans votre registre de sous-traitants. Les plug-ins de type site web constituent un cas particulier à surveiller : ils utilisent une authentification anonyme pour accéder au contenu public — techniquement inoffensif, mais à documenter.

Plug-ins personnalisés : le manifeste, l'API et les collisions

Un plug-in personnalisé se décrit par un fichier manifeste YAML ou JSON (plugin.yaml ou plugin.json) comportant deux clés obligatoires de premier niveau : Descriptor et SkillGroups. Security Copilot accepte à la fois son format natif et le format de manifeste OpenAI, avec une contrainte ferme sur les spécifications API : seules les versions OpenAPI 3.0 et 3.0.1 sont supportées. Le champ api.type n'accepte aujourd'hui que la valeur openapi, et auth.authorization_type est limité à bearer, les types none, oauth, api_key, aad et aad_delegated étant documentés dans la table de correspondance.

La qualité des descriptions n'est pas cosmétique : c'est le mécanisme de sélection de compétence. Description alimente l'interface utilisateur, DescriptionForModel (limité à 16 000 caractères) sert exclusivement à la sélection par le LLM. La collision de compétences — Copilot n'arrive pas à départager deux compétences — est l'échec le plus fréquent des plug-ins maison. Le remède architectural est simple : préférez une compétence GetDevices acceptant plusieurs entrées (identifiant d'appareil, identifiant utilisateur, nom d'utilisateur) à trois compétences GetDeviceById, GetDeviceByUserId et GetDeviceByUserName quasi identiques.

Côté gouvernance, la gestion des plug-ins personnalisés est verrouillée par défaut : seul le propriétaire Copilot peut les gérer, autoriser les contributeurs à gérer leurs plug-ins personnels, autoriser la publication à l'échelle du tenant, ou modifier la disponibilité des plug-ins préinstallés. Un contributeur ne peut, par défaut, ni créer ni publier. La construction d'agents et de bibliothèques d'invites réutilisables est traitée en détail dans notre guide sur la création d'agents et promptbooks personnalisés.

Flux de données : ce qui sort de votre tenant et ce qui n'en sort pas

C'est la section qui décide de l'acceptabilité du produit dans une DSI régulée. Microsoft distingue formellement deux catégories.

Données client contre journaux générés par le système

Les données client comprennent les invites soumises, les informations récupérées pour générer les réponses, les réponses elles-mêmes, le contenu des éléments épinglés et les fichiers chargés. Les journaux générés par le système comprennent les informations de compte (identifiant de tenant, identifiant de compte, licences), les données d'utilisation, les informations de performance et le comportement interne du système. Les seconds relèvent de l'exploitation normale du service et ne sont pas configurables ; les premiers le sont.

Emplacement de stockage et emplacement d'évaluation : deux réglages distincts

La confusion la plus répandue consiste à croire qu'un seul curseur géographique existe. Il y en a deux. L'emplacement de stockage des données client est choisi à la création de l'espace de travail et n'est plus modifiable. L'emplacement d'évaluation des invites détermine où les GPU Azure traitent l'inférence, et se choisit parmi quatre régions : Australie (ANZ), Europe (UE), Royaume-Uni (UK), États-Unis (US) — avec une cinquième option « n'importe où dans le monde » que Microsoft recommande pour la résilience et la latence. Pour un opérateur soumis à NIS2 ou une entité manipulant des données de santé, cette recommandation Microsoft doit être écartée au profit d'un verrouillage explicite sur Europe (UE). En provisionnement automatique, si le stockage est dans l'UE, l'évaluation est déjà positionnée sur l'UE ; sinon elle est globale par défaut.

Les deux commutateurs de partage de données

Deux préférences distinctes, modifiables par le seul propriétaire Copilot, gouvernent la sortie de données vers Microsoft. La première autorise Microsoft à capturer des données pour valider les performances du produit par revue humaine. La seconde autorise Microsoft à capturer et examiner des données pour construire et valider le modèle IA de sécurité de Microsoft, incluant les données issues des plug-ins et agents Microsoft utilisés.

Trois garanties contractuelles encadrent ce second point, et elles sont explicites : les données ne sont pas partagées avec OpenAI, ne sont pas utilisées pour entraîner le modèle de fondation Azure OpenAI, ne sont pas vendues ni partagées avec des tiers. Elles peuvent en revanche servir à développer des modèles spécifiques à la sécurité créés par Microsoft. Le point d'attention majeur est ailleurs : lorsque le partage de données est activé, les données client (hors fichiers chargés) peuvent être stockées en dehors de la géographie de l'espace de travail. Activer le partage de données casse donc de facto la garantie de résidence que vous avez configurée. Pour un tenant sous contrainte de localisation, la position à tenir est binaire : les deux commutateurs restent sur Désactivé.

Rétention, suppression et chiffrement

Les données de session sont conservées tant que l'abonnement est actif. Une session inactive plus de 180 jours est supprimée. La suppression de la totalité de la capacité provisionnée entraîne la suppression des données client sous 180 jours. Une demande explicite de suppression via le portail ou le support est traitée sous 30 jours. Les données partagées avec Microsoft sont conservées 90 jours par l'équipe qui les évalue ; désactiver le partage déclenche leur suppression sous 30 jours. Le chiffrement au repos est systématique en AES-256. Enfin, une nuance réseau souvent absente des analyses d'impact : les communications initiées par des compétences d'agents qui restituent des résultats par e-mail ou dans Microsoft Teams peuvent traverser l'infrastructure réseau mondiale de Microsoft en transit, et donc franchir des frontières géographiques, même si les données au repos ne quittent pas la région de l'espace de travail.

Isolation des tenants et conformité RGPD / NIS2

L'isolation repose sur trois piliers cumulatifs. D'abord l'espace de travail, qui borne stockage, capacité et périmètre de rôles. Ensuite le modèle on-behalf-of : Copilot exécute les requêtes en tant qu'utilisateur et ne dispose jamais de privilèges supérieurs à ceux de l'utilisateur — il n'existe pas de compte de service Copilot à privilèges qui verrait l'ensemble du tenant. Enfin les fichiers chargés, qui sont accessibles uniquement au compte utilisateur qui les a téléversés, ni aux autres utilisateurs du tenant ni à l'extérieur.

RGPD : responsabilités et droits des personnes

Microsoft agit en sous-traitant au sens de l'article 28, sous le couvert des Conditions du produit et de l'Addendum sur la protection des données. La conséquence pratique est que votre analyse d'impact doit documenter précisément quatre éléments : la géographie de l'espace de travail, la région d'évaluation des invites, l'état des deux commutateurs de partage, et l'état du paramètre d'accès aux données des services Microsoft 365. Ce dernier mérite une lecture attentive : Security Copilot n'accède aux données Microsoft 365 que via Microsoft Purview — alertes DLP, journaux d'activité d'étiquetage Microsoft Purview Information Protection, jeux de révision eDiscovery, alertes de gestion des risques internes, correspondances de conformité des communications, données de posture de sécurité des données. Le périmètre exact est donc dicté par ce que votre administrateur Purview a configuré, ce qui inclut potentiellement du contenu de messagerie ou de collaboration. Pour les demandes d'exercice de droits (DSR), le traitement passe par le support Security Copilot, ce qui implique de câbler votre processus DPO sur un canal support et non sur une API en libre-service.

NIS2 : ce que l'auditeur va demander

Pour une entité essentielle ou importante, Security Copilot entre dans le périmètre de l'article 21 au titre de la sécurité de la chaîne d'approvisionnement et de la maîtrise des outils de gestion d'incident. Préparez quatre livrables : la cartographie du flux (portail et embarqué, plug-ins actifs, destinations), la matrice des rôles Copilot avec le principe de moindre privilège appliqué, la preuve du verrouillage géographique et du partage désactivé, et le plan de continuité si la capacité est saturée. Ce dernier point est régulièrement oublié : si Copilot devient un maillon du triage d'incident, sa saturation à 100 % de capacité est un scénario de dégradation qui doit être documenté et testé, au même titre qu'un exercice de pentest Active Directory qui valide la résilience de la chaîne d'identité.

Architecture de référence pour un déploiement en production

Topologie cible

Pour une organisation française mono-tenant, la cible est un espace de travail unique en géographie Europe, adossé à une ressource de capacité Azure isolée dans un groupe de ressources dédié — typiquement rg-securitycopilot-prod — placé sous une étiquette de coût propre et sous un budget Azure avec alertes à 70 %, 90 % et 100 %. La ressource se vérifie en ligne de commande :

az resource list --resource-type Microsoft.SecurityCopilot/capacities --output table

Un second espace de travail ne se justifie que dans deux cas : une contrainte de résidence différenciée par filiale, ou une séparation stricte entre un environnement d'expérimentation de plug-ins personnalisés et la production. Attention alors à l'effet de bord déjà signalé : les expériences embarquées consomment l'espace de travail par défaut, c'est-à-dire le plus ancien créé.

Séquence de déploiement

L'ordre des opérations est important, car plusieurs paramètres sont irréversibles. Un, créer l'espace de travail en fixant la géographie avant toute autre chose. Deux, positionner l'emplacement d'évaluation des invites sur Europe (UE). Trois, désactiver les deux préférences de partage de données. Quatre, statuer explicitement sur l'accès aux données des services Microsoft 365 après revue de la configuration Purview. Cinq, purger le groupe Tout le monde de l'accès contributeur — sachant qu'une fois retiré, il ne peut plus être réattribué. Six, appliquer le groupe Rôles de sécurité Microsoft recommandés ou une affectation personnalisée par groupes de sécurité assignables à un rôle. Sept, provisionner une capacité de démarrage modeste avec dépassement plafonné, et n'ajuster qu'après quatre semaines de données réelles.

Observabilité et FinOps

Instrumentez dès le premier jour. Export mensuel du tableau de bord d'utilisation, ventilation par catégorie et par plug-in, corrélation avec le volume d'incidents Defender XDR pour obtenir un coût par incident traité. C'est le seul indicateur qui tienne devant un comité de direction. En parallèle, surveillez les notifications d'approche de limite : elles remontent aussi bien dans le portail autonome que dans les expériences embarquées, et invitent l'analyste à contacter le propriétaire de capacité ou le contributeur Azure. Faites de cette notification un événement traçable dans votre outil ITSM plutôt qu'un message ignoré en pleine investigation.

Intégration avec Microsoft Entra et gestion des droits d'accès

Trois plans RBAC qu'il ne faut jamais confondre

L'erreur d'architecture la plus courante est de traiter les rôles Copilot comme des rôles Entra. Ce sont trois plans distincts et cumulatifs. Les rôles RBAC Security Copilot — propriétaire Copilot et contributeur Copilot — sont définis et gérés dans Copilot, ne sont pas des rôles Microsoft Entra, et n'accordent par eux-mêmes aucun accès à la moindre donnée de sécurité. Le RBAC Microsoft Entra gouverne l'accès au portefeuille Microsoft, y compris les services contenant les données de sécurité. Le RBAC Azure gouverne les ressources Azure : la capacité SCU dans son groupe de ressources et les espaces de travail Microsoft Sentinel.

L'illustration canonique : un analyste doté du seul rôle contributeur Copilot peut ouvrir des sessions et exécuter des promptbooks, mais ne verra rien. Pour interroger Microsoft Sentinel il lui faut en plus un rôle Azure RBAC tel que Microsoft Sentinel Reader ; pour interroger Intune, un rôle Intune tel que Endpoint Security Manager ; pour Defender XDR, un rôle du RBAC unifié Defender. C'est le comportement attendu et c'est une bonne nouvelle pour le moindre privilège — à condition que le support N1 le sache, faute de quoi il conclura à un dysfonctionnement.

Le piège de l'héritage propriétaire

Plusieurs rôles Entra héritent automatiquement de l'accès propriétaire Copilot : Administrateur général, Administrateur de sécurité, Administrateur de facturation, Administrateur de conformité Entra, Administrateur Intune, ainsi que le rôle Entra ID Intune et les rôles Purview (Administrateur de conformité Purview, Administrateur Gouvernance des données Purview, Gestion de l'organisation Purview). Microsoft l'assume : ce mécanisme garantit qu'il existe toujours au moins deux propriétaires, la plateforme imposant d'ailleurs la conservation permanente de deux propriétaires non supprimables. La contrepartie est un élargissement silencieux du périmètre de propriétaires. La bonne pratique explicite de Microsoft est de ne jamais attribuer Administrateur de sécurité dans le seul but de donner accès à Copilot : créez un groupe de sécurité assignable à un rôle et affectez-le au rôle Copilot adéquat.

Accès conditionnel et sessions partagées

Le RBAC ne suffit pas. Superposez une stratégie d'accès conditionnel Microsoft Entra ciblant les applications Copilot et IA — Microsoft documente un modèle dédié — avec exigence d'authentification multifacteur résistante au phishing et conformité de l'appareil. C'est d'autant plus justifié qu'une session partagée constitue un contournement structurel du contrôle d'accès : lorsqu'un analyste partage un lien de session, le destinataire voit l'intégralité des invites et des réponses de la session, y compris les données issues de plug-ins auxquels il n'a aucun droit. L'accès aux données n'est évalué qu'à la génération de la réponse, jamais à la consultation. Le seul prérequis pour lire une session partagée est le rôle contributeur Copilot dans le même tenant. Traitez donc les sessions comme des exports de données et sensibilisez en conséquence.

Scénarios multi-tenants

Trois modèles d'authentification cohabitent pour les groupes multi-tenants et les MSSP : les comptes invités B2B avec le changement de tenant natif au portail autonome, les privilèges d'administration délégués granulaires (GDAP) via l'Espace partenaires, et Azure Lighthouse via le portail Azure. Le tenant qui provisionne la capacité n'a pas besoin d'être celui depuis lequel les analystes se connectent — un point structurant pour les fusions-acquisitions et les prestataires. Nous détaillons ces topologies dans notre article sur le mode MSSP multi-tenant de Copilot Security.

Anti-patterns observés sur le terrain

Provisionner large « pour voir ». Démarrer à 10 SCU en continu représente environ 29 000 USD mensuels au tarif de référence, pour une utilisation réelle qui plafonne souvent sous 30 % les six premières semaines. Démarrez bas, laissez le dépassement absorber, ajustez sur données.

Activer tous les plug-ins par principe. Chaque plug-in actif élargit la surface de grounding, donc le volume de données envoyées au modèle et le nombre d'appels facturés. Activez par cas d'usage documenté.

Laisser le partage de données activé « puisque Microsoft ne s'en sert pas pour entraîner OpenAI ». L'argument est exact mais hors sujet : le vrai effet est la possibilité de stockage hors géographie de l'espace de travail, ce qui invalide votre engagement de résidence.

Confondre expériences embarquées et gratuité. Un résumé d'incident généré automatiquement dans Defender XDR consomme des SCU comme n'importe quelle invite. Sur une file d'alertes à fort volume, l'automatisation est le premier poste de coût.

Oublier que les préversions publiques sont facturées. Les SCU sont facturées pour les capacités en disponibilité générale et en préversion publique ; seule la préversion privée est gratuite. Tester une fonctionnalité en public preview a un coût réel.

Questions fréquentes

Combien de SCU faut-il provisionner pour démarrer ?

Le minimum technique est d'une SCU provisionnée, mais ce n'est pas un dimensionnement réaliste : le scénario officiel de Microsoft montre une invite unique consommant 3 SCU et un promptbook 3,7 SCU sur une même heure. Pour un SOC de cinq à dix analystes, une base de 3 à 4 SCU en heures ouvrées avec une capacité de dépassement plafonnée constitue un point de départ défendable. Ajustez après quatre semaines à partir du tableau de bord d'utilisation, qui conserve 90 jours d'historique exportables.

Mes données de sécurité servent-elles à entraîner les modèles OpenAI ?

Non. Microsoft indique explicitement que les données client ne sont pas partagées avec OpenAI, ne sont pas utilisées pour entraîner le modèle de fondation Azure OpenAI, ne sont pas vendues et ne sont pas partagées avec des tiers. Si vous activez le second commutateur de partage, elles peuvent en revanche servir à construire et valider des modèles spécifiques à la sécurité créés par Microsoft. Le risque à documenter n'est donc pas l'entraînement d'OpenAI mais la possibilité de stockage hors de la géographie de votre espace de travail lorsque le partage est actif.

Peut-on garantir que le traitement reste dans l'Union européenne ?

Oui, sous trois conditions cumulatives : créer l'espace de travail avec un emplacement de stockage en Europe — choix irréversible —, fixer l'emplacement d'évaluation des invites sur Europe (UE) au lieu de l'option « n'importe où » recommandée par Microsoft pour la performance, et laisser les deux préférences de partage de données désactivées. Réserve à documenter : les communications sortantes déclenchées par des agents vers l'e-mail ou Microsoft Teams peuvent transiter par l'infrastructure réseau mondiale de Microsoft.

Un analyste avec le rôle contributeur Copilot voit-il toutes les données de sécurité ?

Non. Les rôles Security Copilot ne sont pas des rôles Microsoft Entra et n'accordent par eux-mêmes aucun accès aux données. Un contributeur peut créer des sessions et exécuter des promptbooks, mais il lui faut les rôles de service correspondants — Microsoft Sentinel Reader côté Azure RBAC, un rôle Intune tel qu'Endpoint Security Manager, un rôle du RBAC unifié Defender XDR — pour que les plug-ins retournent quoi que ce soit. Une exception importante existe cependant : les sessions partagées affichent les résultats complets sans réévaluer les droits du destinataire.

Que se passe-t-il si la capacité est épuisée pendant un incident majeur ?

Les analystes reçoivent d'abord une notification d'approche de limite, dans le portail autonome comme dans les expériences embarquées. Une fois les unités provisionnées et de dépassement consommées à 100 %, un message d'erreur bloque toute nouvelle invite jusqu'à l'heure de facturation suivante. L'augmentation de capacité par le propriétaire ou le contributeur Azure prend jusqu'à 30 minutes pour être effective. C'est pourquoi le choix entre dépassement plafonné et illimité doit être arbitré en amont, et la saturation traitée comme un scénario de continuité documenté.

``` Quelques points à signaler : - **Volume** : ~3 600 mots (estimation ; je n'ai pas pu écrire dans `/tmp` pour lancer un `wc -w`, l'écriture ayant été refusée). Chapeau à ~200 mots, 10 `

` pour rester sous le ratio H2/mots de 350. - **Tarif SCU** : le seul chiffre que je n'ai pas pu revérifier en ligne — `learn.microsoft.com` ne publie pas le tarif et les accès à `azure.microsoft.com` / WebSearch ont été refusés. J'ai retenu le tarif public de référence de 4 USD/SCU/heure (≈2 900 USD/mois pour 1 SCU en continu) en invitant explicitement à le vérifier sur la calculatrice Azure. Tout le reste (blocs horaires fixes, minimum 1 SCU, facturation décimale du dépassement, scénario 4+3,2 SCU, rétentions 30/90/180 jours, AES-256, quatre régions d'évaluation, matrice de rôles, OpenAPI 3.0/3.0.1, `bearer`) provient des pages Learn à jour. - **Provisionnement automatique E5/E7** : c'est du contenu 2026 récent que j'ai vérifié — inversion des défauts de partage de données (Désactivé en auto-provisioning, Activé sinon) et héritage élargi du rôle propriétaire. C'est l'angle le plus différenciant de l'article. - Aucun `

` dans les boîtes `rex-box` / `a-retenir`, conformément à la règle heading-order.