Microsoft Copilot Security : dimensionner ses Security Compute Units (SCU)

Les permissions d'écriture fichier ne sont pas accordées dans cette session non-interactive. Je livre donc l'article directement ci-dessous. **Trois corrections d'arithmétique appliquées** (les chiffres du brief se contredisaient) : - **Breakeven à 730 h/mois, pas 365 h.** 2 920 ÷ 4 = 730 : le tarif provisionné est exactement 4 $/h facturé en continu, sans remise de volume. À 365 h, le PAYG coûte 1 460 $ contre 2 920 $ — deux fois moins cher. - **L'exemple « 8h/jour → 960 $ → plus cher que le provisionné » était inversé** : 960 $ < 2 920 $, le PAYG est 3× moins cher. Les deux exemples du brief favorisaient en réalité le PAYG. - **6 SCU provisionnées = 210 240 $/an**, pas ~120 k$ (cela change la conclusion du make-vs-buy) — et le **POC = 1 408 $**, pas 2 816 $ (352 SCU-h × 4 $). L'angle en résulte, et il est plus solide pour un lectorat avancé : on achète du provisionné pour la **garantie de capacité et la prévisibilité budgétaire**, jamais pour une remise. J'ai aussi ajouté 4 H2 (prérequis, erreurs de dimensionnement, mesure en POC, feuille de route 12 mois) pour tenir le ratio H2/mots ≤ 350. ```html

La question du budget est systématiquement la première posée par les RSSI, bien avant celle de l'intégration technique ou de la couverture fonctionnelle : « combien va me coûter Copilot Security en régime de croisière ? ». Cette interrogation n'a rien de trivial, car Microsoft a retenu pour cette plateforme un modèle de facturation à la capacité — la Security Compute Unit, ou SCU — et non un modèle par siège comme pour Microsoft 365 Copilot. Autrement dit, la facture ne dépend pas du nombre d'analystes déclarés mais de l'intensité réelle d'usage de la plateforme, ce qui rend toute estimation à la louche dangereuse : les écarts constatés entre le dimensionnement initial et la consommation effective atteignent couramment un facteur 2 à 3 dans les déploiements observés. Cet article propose un cadre de dimensionnement rigoureux, appuyé sur les modèles d'usage réels observés en 2026 dans des SOC internes, des ETI et des MSSP. Il détaille la mécanique de consommation d'une SCU, compare sans complaisance les deux modèles de tarification, fournit les formules de calcul de charge journalière, corrige plusieurs raccourcis de calcul largement répandus dans les présentations commerciales, et donne des profils de référence chiffrés par taille d'organisation. L'objectif est simple : permettre à un acheteur IT ou à un architecte sécurité de construire un business case défendable devant un comité d'investissement, avec des hypothèses explicites et un seuil de bascule mathématiquement fondé.

Qu'est-ce qu'une Security Compute Unit (SCU) ?

Définition technique

Une Security Compute Unit est l'unité d'allocation de puissance de calcul dédiée au traitement des requêtes Copilot Security. Elle ne mesure ni un volume de données ingérées, ni un nombre d'utilisateurs, ni un nombre de requêtes : elle mesure une capacité de traitement instantanée. L'analogie la plus juste est celle du vCPU dans un modèle IaaS classique : provisionner 4 vCPU sur une machine virtuelle ne détermine pas combien de calculs vous ferez dans le mois, mais combien vous pouvez en faire en même temps à un instant donné.

Cette distinction est fondamentale pour le dimensionnement. Une organisation qui traite 200 incidents par jour répartis uniformément sur 24 heures aura besoin de moins de SCU qu'une organisation traitant 100 incidents concentrés sur la fenêtre 8h-11h. Ce n'est pas le volume qui dicte le nombre de SCU, c'est le pic de concurrence.

La granularité de facturation est horaire dans le modèle provisionné, et à la seconde dans le modèle à l'usage — une nuance qui a des conséquences réelles sur le coût d'un POC, comme nous le verrons. Une SCU allouée est réservée à votre tenant pour la durée d'allocation, qu'elle soit sollicitée ou non : c'est un modèle de réservation de capacité, pas un modèle de consommation à la requête.

Ce qu'une SCU consomme réellement

Chaque action déclenchée dans Copilot Security mobilise de la capacité pendant une durée variable. Un prompt simple sollicite brièvement une fraction de SCU ; un agent autonome d'investigation peut mobiliser plusieurs SCU pendant plusieurs minutes. Le tableau ci-dessous synthétise les ordres de grandeur observés, exprimés en SCU-heures équivalentes pour permettre les additions.

Action	Consommation estimée	Fréquence SOC typique
Prompt simple (question de contexte)	0,1 - 0,3 SCU	Très fréquent
Promptbook Risky User Summary	0,8 - 1,2 SCU	10 - 20 / jour
Promptbook Incident Prioritization	1,0 - 1,8 SCU	5 - 15 / jour
Génération KQL (NL2KQL)	0,3 - 0,5 SCU	20 - 50 / jour
Agent autonome d'investigation	2 - 5 SCU	3 - 8 / jour
Analyse de script malveillant / désobfuscation	1,5 - 3 SCU	2 - 5 / jour

Trois facteurs font varier ces valeurs à l'intérieur des fourchettes. Le premier est le nombre de plugins actifs : chaque plugin interrogé (Defender XDR, Sentinel, Intune, Entra ID, Threat Intelligence, plugins tiers) ajoute un aller-retour d'enrichissement. Le deuxième est la profondeur de session : une session d'investigation qui accumule vingt échanges consomme davantage qu'une session de trois échanges, car le contexte accumulé est retraité. Le troisième est la volumétrie des données retournées : une requête KQL ramenant 50 000 lignes coûte davantage à synthétiser qu'une requête ramenant 50 lignes.

Ce dernier point mérite qu'on s'y arrête : la discipline dans l'écriture des requêtes n'est pas seulement une bonne pratique d'ingénierie, c'est un levier budgétaire direct. Un analyste qui lance un SecurityEvent | where TimeGenerated > ago(90d) sans filtre supplémentaire consomme plusieurs fois ce que consommerait la même investigation correctement bornée.

Prérequis et dépendances : ce qu'il faut avant de parler budget

Avant tout calcul de dimensionnement, un contrôle d'éligibilité s'impose. Copilot Security n'apporte de valeur que s'il dispose de sources de données à interroger. Concrètement, le socle minimal viable est constitué de Microsoft Defender XDR — idéalement en édition P2 — et/ou de Microsoft Sentinel avec une rétention d'au moins 90 jours sur les tables d'investigation. Une organisation qui déploie Copilot Security sans Sentinel ni Defender obtiendra des réponses génériques de type moteur de recherche documentaire, sans valeur opérationnelle.

Il faut également budgéter les coûts adjacents, trop souvent oubliés dans les business cases :

• Coût d'ingestion Sentinel : Copilot interroge les tables Log Analytics. Étendre la rétention de 90 à 180 jours pour améliorer la qualité des investigations a un coût propre, indépendant des SCU.
• Licences Defender XDR P2 : les fonctions d'investigation avancées les plus utiles à Copilot en dépendent.
• Coût d'adoption : deux à quatre semaines de montée en compétence par analyste, pendant lesquelles la consommation de SCU est paradoxalement supérieure à celle du régime de croisière — les prompts mal formulés sont relancés.
• Gouvernance des identités : Copilot hérite des permissions de l'utilisateur qui l'interroge. Un modèle RBAC mal structuré produit des réponses incomplètes qui seront relancées, donc facturées deux fois.

Ce dernier point est celui qui surprend le plus souvent en phase pilote : la qualité du modèle d'habilitation conditionne directement le taux de relance, et donc le coût. Nous détaillons ces prérequis d'architecture dans notre analyse de l'architecture SCU et plugins de Copilot Security.

Modèles de tarification : Pay-as-you-go vs Provisioned

Pay-as-you-go (à l'usage)

Le modèle à l'usage facture environ 4 $ par SCU et par heure, avec une granularité à la seconde. Aucun engagement de durée n'est requis : la capacité est allouée puis libérée à la demande, y compris de façon programmatique via l'API de gestion de capacité ou un runbook Azure Automation.

La formule de coût est directe :

Coût mensuel = Nombre de SCU × Heures d'allocation dans le mois × 4 $

Ce modèle est optimal pour les phases de POC, les pilotes, les usages irréguliers, et — point souvent ignoré — pour toute organisation dont l'activité SOC est calée sur des horaires ouvrés. Un SOC qui ne fonctionne pas en 24/7 n'a aucune raison de payer une capacité nocturne inutilisée.

Provisioned (provisionné)

Le modèle provisionné correspond à une allocation permanente, facturée environ 2 920 $ par mois et par SCU. La capacité est garantie et disponible 24 heures sur 24, avec un engagement mensuel.

Un calcul élémentaire s'impose ici, car il est constamment escamoté dans les présentations commerciales : 2 920 ÷ 4 = 730. Le tarif provisionné correspond très exactement à 730 heures de tarif horaire, soit une allocation continue sur un mois moyen (365 × 24 ÷ 12 = 730 h). Il n'y a donc aucune remise de volume dans le passage au provisionné : c'est le même prix horaire, simplement facturé en continu.

Tableau comparatif Pay-as-you-go vs Provisioned

Critère	Pay-as-you-go	Provisionné
Prix unitaire	~4 $ / SCU / heure	~2 920 $ / SCU / mois (= 4 $/h en continu)
Granularité de facturation	À la seconde	Mensuelle
Engagement	Aucun, arrêt immédiat	Mensuel reconductible
Garantie de disponibilité	Best effort — capacité soumise à la disponibilité régionale	Capacité réservée et garantie 24/7
Prévisibilité budgétaire	Faible — dérive possible lors d'un incident majeur	Totale — ligne budgétaire fixe
Cas d'usage optimal	POC, pilote, SOC en horaires ouvrés, capacité de débordement	SOC 24/7, agents autonomes permanents, MSSP
Point d'équivalence	730 h/mois — au-delà, le provisionné devient moins cher ; en dessous, l'usage reste plus économique

Breakeven : quand basculer du pay-as-you-go au provisionné ?

La formule de bascule est la suivante :

Heures d'usage mensuel × 4 $ > 2 920 $  ⟺  Heures d'usage mensuel > 730 h

Or un mois moyen compte 730 heures. Le seuil arithmétique correspond donc à une utilisation de 100 % du temps. Deux exemples chiffrés le montrent sans ambiguïté :

• SOC en horaires étendus, 8 h/jour, 30 jours/mois : 8 × 30 = 240 h → 240 × 4 = 960 $ par SCU et par mois. Face aux 2 920 $ du provisionné, le pay-as-you-go est trois fois moins cher.
• Usage modéré, 4 h/jour : 120 h → 120 × 4 = 480 $ par SCU et par mois, soit six fois moins que le provisionné.
• SOC 24/7 réel : 730 h → 2 920 $, strictement équivalent — et à ce niveau le provisionné l'emporte pour d'autres raisons que le prix.

La conclusion, contre-intuitive pour qui a l'habitude des réservations Azure Reserved Instances, est nette : on ne bascule pas vers le provisionné pour économiser, on y bascule pour acheter de la garantie de capacité et de la prévisibilité budgétaire. Les trois motifs légitimes de passage au provisionné sont :

1. La garantie de disponibilité pendant un incident majeur. En pay-as-you-go, l'allocation d'une capacité supplémentaire dépend de la disponibilité régionale à l'instant T. Pendant une crise, l'indisponibilité de capacité est un risque opérationnel inacceptable.
2. Les agents autonomes permanents. Un agent de triage de phishing ou de tri d'alertes qui tourne en continu occupe la capacité 24/7 par construction : la question du breakeven ne se pose même pas.
3. La prévisibilité comptable. Une ligne budgétaire fixe est souvent préférée par une DAF à une facture variable, même si l'espérance de coût est plus élevée. C'est un arbitrage de gouvernance, pas d'optimisation.

L'architecture la plus efficiente combine les deux : un socle provisionné couvrant la charge de base et les agents permanents, complété par du pay-as-you-go en débordement pour absorber les pics.

Méthode de dimensionnement : combien de SCU pour mon organisation ?

Étape 1 : qualifier votre charge SOC

Le dimensionnement commence par une mesure, pas par une estimation. Les cinq variables à collecter sur au moins quatre semaines glissantes sont :

• Nombre d'incidents par jour, ventilé par sévérité (P1 / P2 / P3). La ventilation compte davantage que le volume : un P1 consomme 3 à 5 fois ce que consomme un P3.
• Nombre d'alertes traitées par jour, à distinguer des incidents corrélés.
• Nombre d'analystes utilisant Copilot simultanément — c'est la variable de concurrence, la plus déterminante.
• Durée moyenne d'une session d'investigation, mesurée du premier au dernier prompt.
• Répartition des types d'actions : triage, hunting proactif, reporting, analyse de code. Un SOC orienté hunting consomme un profil très différent d'un SOC orienté triage.

Une remarque méthodologique importante : la distribution horaire des incidents doit être tracée. Un histogramme par tranche horaire révèle le pic de concurrence, qui est la grandeur réellement dimensionnante.

Étape 2 : calculer la charge SCU journalière

Prenons un SOC de 5 analystes, en horaires étendus 8h-18h, sur une organisation d'environ 4 000 postes. La charge journalière se décompose ainsi :

Activité	Volume	Coût unitaire	Total SCU
Triage matinal (incidents nuit + matin)	15 incidents	1,2 SCU	18 SCU
Hunting et requêtes KQL	10 sessions	0,4 SCU	4 SCU
Investigations approfondies P1	3 incidents	3 SCU	9 SCU
Reporting et synthèses direction	2 rapports	0,5 SCU	1 SCU
Total journalier	—	—	32 SCU-h

Ces 32 SCU-heures sont consommées sur une fenêtre active de 8 heures. La charge moyenne est donc de 32 ÷ 8 = 4 SCU en moyenne. Mais la moyenne ne dimensionne rien : le triage matinal concentre 18 SCU-h sur environ 3 heures, soit un pic à 6 SCU par heure. C'est ce pic qui détermine la capacité nécessaire.

Capacité de base = max(charge horaire) = 6 SCU

Le coût correspondant en pay-as-you-go, pour 6 SCU allouées 8 h/jour sur 22 jours ouvrés : 6 × 8 × 22 × 4 = 4 224 $/mois. En provisionné : 6 × 2 920 = 17 520 $/mois. L'écart de 4,1× justifie à lui seul de commencer par le modèle à l'usage.

Étape 3 : ajouter la marge pour les pics

Les incidents majeurs — compromission Active Directory, campagne de ransomware, exfiltration détectée — consomment 3 à 5 fois la charge normale, avec toute l'équipe mobilisée simultanément sur le même dossier. Deux stratégies coexistent :

• Marge forfaitaire de 30 % sur le dimensionnement de base. Dans notre exemple : 6 × 1,3 ≈ 8 SCU. Simple, mais on paye la marge en permanence si elle est provisionnée.
• Socle + débordement : provisionner 4 SCU pour la charge incompressible, et conserver une réserve de 4 SCU en pay-as-you-go activable en quelques minutes. Coût du socle : 11 680 $/mois ; coût de la réserve si elle sert 20 h dans le mois : 4 × 20 × 4 = 320 $. C'est le modèle recommandé.

Une précaution opérationnelle accompagne le modèle de débordement : la procédure d'augmentation de capacité doit être documentée dans le playbook de crise et testée. Découvrir en pleine crise que seul le titulaire du rôle Owner peut augmenter la capacité, et qu'il est injoignable, est un scénario réel.

Étape 4 : profils de référence par taille d'organisation

Profil	Analystes SOC	Incidents/jour	SCU recommandées	Budget mensuel (provisionné)
PME sans SOC dédié	1 - 2	5 - 15	1 - 2 SCU	2 920 - 5 840 $
ETI avec SOC partiel	3 - 5	15 - 50	3 - 5 SCU	8 760 - 14 600 $
Grande entreprise, SOC 24/7	6 - 15	50 - 200	6 - 12 SCU	17 520 - 35 040 $
MSSP (10 clients)	10 - 25	200 - 500	15 - 25 SCU	43 800 - 73 000 $

Tarifs indicatifs 2026, hors remises contractuelles. Les montants sont exprimés en modèle provisionné intégral. Pour les profils PME et ETI, qui fonctionnent rarement en 24/7, le coût réel en pay-as-you-go est typiquement 3 à 6 fois inférieur : une PME en horaires ouvrés avec 2 SCU sur 8 h/jour et 22 jours ouvrés paye 2 × 8 × 22 × 4 = 1 408 $/mois au lieu de 5 840 $.

Cette dernière remarque est la plus importante du tableau. Les grilles de budget circulant chez les revendeurs présentent presque toujours les montants provisionnés, ce qui surestime le coût réel d'un déploiement PME/ETI d'un facteur 4.

Les erreurs de dimensionnement les plus fréquentes

Cinq erreurs reviennent systématiquement dans les projets observés.

1. Dimensionner sur le volume plutôt que sur la concurrence. « Nous avons 100 incidents par jour, donc il nous faut beaucoup de SCU » est un raisonnement faux. Ce qui compte est le nombre d'actions simultanées au pic. Un SOC de 3 analystes ne peut pas générer plus de 3 sessions concurrentes, quel que soit le volume d'incidents en file d'attente.

2. Provisionner dès le premier jour. C'est la cause principale du sur-provisionnement d'un facteur 2 à 3. La consommation en phase d'apprentissage n'est pas représentative du régime permanent, et elle est presque toujours supérieure.

3. Oublier les agents autonomes dans le calcul. Un agent de triage qui tourne en continu occupe de la capacité 24/7. Trois agents permanents peuvent représenter 40 à 60 % de la consommation totale d'une organisation, sans qu'aucun analyste n'ait tapé un prompt.

4. Ignorer les fuseaux horaires dans les groupes internationaux. Un SOC suivant le soleil sur trois régions n'a pas 8 heures d'activité mais 24 : le breakeven vers le provisionné est atteint, contrairement à un SOC mono-site.

5. Ne pas cloisonner les environnements. Une équipe de tests qui expérimente des promptbooks sur la même capacité que la production peut saturer les SCU pendant une crise réelle. La gouvernance par rôles n'est pas une formalité de conformité, c'est une protection de la capacité opérationnelle.

Optimiser la consommation de SCU

Les 5 pratiques qui réduisent la consommation inutile

1. Privilégier les promptbooks aux prompts improvisés. Un promptbook prédéfini enchaîne des étapes dont le contexte est réutilisé d'une étape à l'autre, là où une succession de prompts libres reconstruit le contexte à chaque fois. L'économie mesurée est de l'ordre de 20 % sur une investigation équivalente, avec un bénéfice secondaire non négligeable : la reproductibilité des analyses entre analystes de niveaux différents.

2. Désactiver les plugins non utilisés. Chaque plugin actif est susceptible d'être interrogé lors de la résolution d'un prompt. Une organisation qui n'utilise pas Intune n'a aucune raison de laisser le plugin Intune actif : c'est du temps de traitement et de la capacité consommés pour un résultat vide. Un audit trimestriel des plugins actifs est une pratique de bonne gestion.

3. Maintenir les sessions ouvertes plutôt que de relancer. Fermer une session et en rouvrir une pour poser une question de suivi oblige la plateforme à reconstruire le contexte d'investigation. Le réflexe « une question = une nouvelle session », fréquent chez les analystes venant d'outils de recherche classiques, est un gaspillage direct.

4. Cibler les requêtes NL2KQL. Fournir le nom exact de la table dans le prompt — « génère une requête sur DeviceProcessEvents pour... » plutôt que « trouve les processus suspects » — supprime les tentatives de résolution de schéma. Le gain est double : moins de capacité consommée, et une requête généralement plus juste du premier coup.

5. Décaler les traitements automatisés en heures creuses. Rapports hebdomadaires, campagnes d'analyse rétrospective, agents de revue de posture : rien n'impose de les exécuter à 9h du matin, précisément quand les analystes ont besoin de la capacité. Un simple décalage à 3h du matin libère plusieurs SCU au pic matinal et peut éviter d'en provisionner une supplémentaire.

Monitoring de la consommation

Le portail Copilot Security expose un tableau de bord d'utilisation accessible aux détenteurs du rôle Owner. Il permet de ventiler la consommation par utilisateur, par plugin et par jour, et de configurer des alertes de seuil. Trois indicateurs méritent un suivi hebdomadaire :

• Le taux d'occupation au pic — si vous êtes à 95 % du plafond plusieurs jours par semaine, vous êtes sous-dimensionné et vos analystes subissent des files d'attente.
• La consommation par analyste — un écart de 5× entre deux analystes de même niveau signale un besoin de formation, pas un besoin de capacité supplémentaire.
• La part des agents autonomes — c'est le poste qui dérive le plus silencieusement.

Les données d'usage s'exportent vers Azure Cost Management, ce qui permet d'intégrer Copilot Security dans le reporting FinOps existant et de rattacher la consommation à des centres de coût via les tags. La documentation Microsoft sur la gestion de l'usage détaille la configuration de ces exports.

Gouvernance et quotas par équipe

L'attribution de capacité par équipe ou par projet se pilote depuis les Owner settings. La politique d'usage doit répondre explicitement à trois questions : qui est autorisé à déclencher des agents autonomes — les plus gros consommateurs ; qui peut modifier la capacité allouée ; et qui est restreint aux prompts manuels et promptbooks validés.

Dans les organisations matures, on observe une segmentation en trois niveaux : les analystes N1 disposent d'un accès aux promptbooks validés uniquement ; les analystes N2/N3 accèdent aux prompts libres et au hunting ; seuls les responsables SOC et les ingénieurs sécurité peuvent créer et déclencher des agents. Cette segmentation est autant une mesure de maîtrise budgétaire qu'une mesure de qualité.

Mesurer sa consommation réelle pendant la phase POC

Le POC n'a pas pour seul objet de valider la valeur fonctionnelle : c'est avant tout l'instrument de mesure qui fondera le dimensionnement. Un protocole exploitable tient en quatre points.

Durée et périmètre. Trente jours calendaires minimum, incluant au moins un cycle mensuel complet (clôture, patch Tuesday, campagne de phishing simulée). Deux SCU en pay-as-you-go, allouées 8 h par jour ouvré : 2 × 8 × 22 = 352 SCU-heures, soit 1 408 $ pour l'ensemble du POC. C'est un budget de découverte négligeable au regard d'un engagement annuel à six chiffres.

Population. Trois à cinq analystes représentatifs des différents niveaux, pas uniquement les plus expérimentés. Les analystes N1 sont ceux dont les gains sont les plus mesurables, et leur consommation est souvent la plus élevée en phase d'apprentissage.

Métriques à collecter. Consommation SCU journalière et au pic ; temps moyen de traitement d'un incident avec et sans Copilot, sur des populations d'incidents comparables ; taux de relance de prompts ; nombre d'investigations abandonnées faute de compétence KQL avant/après.

Décision. À l'issue du POC, on extrapole la consommation observée à la population cible complète, on applique la marge de pic de 30 %, et seulement alors on arbitre entre socle provisionné et usage. Notre guide pratique de démarrage Copilot Security détaille le déroulé opérationnel de cette phase.

Cas d'usage et ROI par profil

SOC interne : la question make vs buy

La comparaison la plus fréquemment demandée en comité d'investissement oppose le recrutement d'un analyste supplémentaire à l'acquisition de capacité Copilot. Posons les chiffres.

Un analyste SOC de niveau L2 en France coûte 70 000 à 90 000 € bruts annuels, soit un coût employeur chargé de l'ordre de 100 000 à 130 000 €, auquel s'ajoutent les coûts indirects (recrutement, formation, poste de travail, turnover). Le délai de recrutement et de montée en compétence est de six à neuf mois.

En face, 6 SCU représentent :

• En provisionné intégral : 6 × 2 920 × 12 = 210 240 $ par an, soit environ deux analystes L2 chargés.
• En pay-as-you-go sur horaires ouvrés (8 h × 22 jours) : 6 × 8 × 22 × 12 × 4 = 50 688 $ par an, soit environ un demi-poste d'analyste.

L'écart entre ces deux lignes change radicalement la conclusion du business case, et c'est précisément pourquoi le mode de facturation doit être arbitré avant de présenter le dossier. Un déploiement en horaires ouvrés bien dimensionné coûte moins cher qu'un recrutement et est opérationnel en quelques semaines ; un déploiement provisionné 24/7 coûte l'équivalent de deux postes et ne se justifie que si le SOC fonctionne réellement en continu.

Sur le gain de productivité, les études Microsoft avancent un facteur de 2 à 3× sur la capacité de traitement des analystes existants, avec des gains particulièrement marqués sur le triage de premier niveau et la génération de requêtes de hunting. Ces chiffres doivent être reçus avec prudence : ils portent sur des tâches de niveau N1/N2 standardisées. Sur les incidents critiques, où le jugement, la connaissance du contexte métier et la coordination de crise dominent, le gain est marginal. Copilot Security multiplie la capacité de traitement du volume ; il ne remplace pas le jugement humain sur les incidents qui comptent. Nous développons cette analyse de ROI dans notre article sur le déploiement en entreprise et le ROI de Copilot Security.

MSSP : le modèle multi-tenant

Le cas MSSP est celui où l'économie du modèle SCU est la plus favorable, pour une raison structurelle : la mutualisation des pics. Via Azure Lighthouse, une capacité SCU unique dessert plusieurs tenants clients depuis le tenant du prestataire.

Prenons un MSSP de 10 clients moyens. Dimensionné client par client, chacun nécessiterait 3 à 4 SCU en tenant compte de sa propre marge de pic, soit 30 à 40 SCU au total. En pool mutualisé, 25 SCU suffisent : la charge moyenne s'établit à 2,5 SCU par client, et les pics — qui sont par nature décorrélés entre clients — sont absorbés par la capacité laissée libre par les autres. L'économie de mutualisation est de l'ordre de 25 à 35 %.

Deux conditions techniques encadrent ce modèle. D'une part, la refacturation exige une traçabilité par tenant : les métadonnées d'usage permettent d'attribuer la consommation à chaque client, mais le dispositif de refacturation doit être construit explicitement. D'autre part, le risque de contention doit être géré contractuellement — un client subissant un incident majeur peut absorber une part disproportionnée du pool. Les MSSP matures définissent des quotas plancher garantis par client, avec un pool de débordement partagé. Le sujet est traité en profondeur dans notre analyse du modèle MSSP multi-tenant pour Copilot Security.

Phase POC : budget et durée

Récapitulons le chiffrage du POC type : 2 SCU en pay-as-you-go, 8 h par jour ouvré, sur 22 jours, soit 352 SCU-heures à 4 $ = 1 408 $. Pour une organisation qui envisage un engagement annuel de 100 000 à 200 000 $, consacrer moins de 1 % de ce montant à la mesure préalable relève de l'évidence économique — et c'est pourtant l'étape la plus souvent sautée sous la pression commerciale de fin de trimestre.

Copilot Security vs alternatives budgétaires

Comparaison avec les solutions concurrentes

Critère	Microsoft Copilot Security	Google Chronicle / SecOps	Splunk SOAR	CrowdStrike Charlotte AI
Modèle de facturation	Capacité (SCU horaire)	Volume de données ingérées	Par utilisateur / par workflow	Module additionnel par endpoint
Prévisibilité du coût	Élevée en provisionné, variable à l'usage	Moyenne — dépend de la volumétrie	Élevée	Élevée
Intégration native	Excellente sur l'écosystème Microsoft (Defender, Sentinel, Entra, Intune, Purview)	Excellente sur Google Cloud, bonne multi-cloud	Très large via connecteurs, effort d'intégration	Excellente sur Falcon, limitée hors écosystème
Support du français	Interface et prompts en français	Partiel	Interface anglaise	Partiel
Playbooks / promptbooks	Promptbooks natifs + personnalisés	Playbooks SOAR matures	Bibliothèque SOAR la plus étendue	Workflows guidés, catalogue plus restreint
Maturité (2026)	En consolidation rapide, agents autonomes récents	Mature sur le SIEM, IA plus récente	Très mature sur l'orchestration	Mature sur l'endpoint

La comparaison a ses limites : ces produits ne couvrent pas exactement le même périmètre. Splunk SOAR et Chronicle sont des plateformes d'orchestration, Charlotte AI est un assistant adossé à une plateforme endpoint, Copilot Security est un assistant transverse à l'écosystème Microsoft. Le critère de choix dominant reste, dans les faits, l'écosystème déjà en place.

Quand Copilot Security n'est pas justifié

Trois situations rendent l'investissement difficilement défendable :

• Absence de Microsoft Defender XDR ou de Sentinel. Sans sources de données natives, Copilot n'a rien à interroger. Le ROI est structurellement faible, quel que soit le dimensionnement.
• Équipe sécurité de moins de deux personnes. Le volume d'usage ne permet pas d'amortir le coût fixe d'adoption : formation, construction des promptbooks, gouvernance. Un service managé externalisé est généralement plus rationnel.
• Moins de 5 incidents par jour en moyenne. En dessous de ce seuil, le gain de productivité agrégé reste inférieur au coût, même en pay-as-you-go optimisé.

Un quatrième cas mérite d'être signalé : les organisations dont les contraintes de souveraineté ou de localisation des données interdisent le traitement hors de certaines régions doivent vérifier la disponibilité régionale du service avant tout engagement budgétaire.

Négocier son contrat Microsoft

Le tarif catalogue est un point de départ, pas un point d'arrivée. Quatre leviers de négociation existent.

L'Enterprise Agreement (EA). Des remises de volume deviennent négociables à partir de 10 SCU provisionnées, avec des paliers supplémentaires au-delà de 25. Le levier est d'autant plus fort que Copilot Security est intégré à une renégociation globale incluant M365 E5, Defender et Azure : isoler la négociation SCU affaiblit la position de l'acheteur.

Le Microsoft Customer Agreement (MCA). Plus souple que l'EA, il convient aux organisations qui veulent démarrer sans engagement pluriannuel, mais offre moins de leviers de remise.

L'essai gratuit. Une période d'essai de 90 jours est proposée aux clients disposant déjà de Defender XDR P2. C'est un levier majeur, trop peu exploité : combiné à un POC pay-as-you-go, il permet de mesurer la consommation réelle à coût quasi nul avant tout engagement.

Le canal CSP. Passer par un partenaire Microsoft ouvre des remises supplémentaires et, surtout, un accompagnement au dimensionnement. Pour une ETI sans expertise interne sur le sujet, la valeur ajoutée du partenaire dépasse souvent la remise obtenue.

Les conditions exactes évoluent : la page officielle de tarification Azure reste la référence à consulter avant toute décision d'engagement.

Feuille de route budgétaire sur 12 mois

Une trajectoire type, applicable à une ETI de 3 000 à 5 000 postes, se déroule ainsi.

Période	Actions	Modèle	Coût indicatif
Mois 1	POC mesuré, 3 analystes, 2 SCU	Pay-as-you-go	~1 400 $
Mois 2-3	Extension à toute l'équipe, construction des promptbooks	Pay-as-you-go, 4 SCU	~2 800 $/mois
Mois 4	Analyse de la consommation, décision d'architecture	Pay-as-you-go	~2 800 $
Mois 5-8	Socle provisionné 2 SCU + débordement PAYG, premiers agents	Hybride	~7 500 $/mois
Mois 9-12	Régime stable, optimisation, négociation EA	Hybride optimisé	~7 000 $/mois

Le point de bascule vers l'hybride au mois 5 n'est pas dicté par le prix — nous avons montré que le pay-as-you-go reste moins cher en horaires ouvrés — mais par l'arrivée des agents autonomes permanents, qui consomment de la capacité 24/7 et justifient un socle provisionné. C'est le déclencheur à surveiller.

Questions fréquentes sur les SCU Copilot Security

Peut-on augmenter les SCU en cours de mois ?

Oui. La capacité provisionnée est modifiable à tout moment depuis les paramètres Owner du portail Copilot Security, et l'augmentation est effective en quelques minutes. La facturation est ajustée au prorata pour le mois en cours. La diminution est également possible, mais elle ne prend effet qu'au cycle de facturation suivant pour la partie provisionnée. En pratique, le mécanisme le plus réactif reste l'ajout de capacité pay-as-you-go, qui se libère aussi vite qu'il s'alloue.

Les SCU sont-elles partagées entre Microsoft 365 Copilot et Copilot Security ?

Non, ce sont deux modèles économiques entièrement distincts. Microsoft 365 Copilot est facturé par siège et par mois, avec une licence attachée à un utilisateur nommé. Copilot Security est facturé à la capacité, indépendamment du nombre d'utilisateurs. Une organisation peut déployer l'un sans l'autre, et les consommations ne communiquent pas. C'est une confusion fréquente en comité budgétaire : les deux lignes doivent être présentées séparément.

Que se passe-t-il quand on atteint le quota de SCU ?

Les requêtes ne sont pas rejetées : elles sont mises en file d'attente et traitées lorsque de la capacité se libère. L'effet visible est une dégradation du temps de réponse, qui peut passer de quelques secondes à plusieurs minutes en situation de saturation. Aucune donnée n'est perdue, mais l'expérience analyste se dégrade nettement — et en situation de crise, c'est exactement le moment où la latence est inacceptable. Les alertes de seuil doivent être configurées à 80 % d'occupation pour anticiper.

Comment suivre la consommation de SCU en temps réel ?

Le tableau de bord d'utilisation du portail Copilot Security fournit une vue quasi temps réel, ventilée par utilisateur, par plugin et par jour. Pour un suivi intégré au FinOps de l'organisation, l'export vers Azure Cost Management permet de construire des tableaux de bord consolidés et d'imputer la consommation aux centres de coût via les tags. Les organisations les plus avancées poussent ces métriques dans Sentinel pour corréler consommation SCU et volumétrie d'incidents, ce qui permet de détecter les dérives d'usage.

Les SCU sont-elles facturées par tenant ou par utilisateur ?

Par tenant. La capacité est allouée au niveau du tenant Azure et partagée entre tous les utilisateurs habilités, sans licence individuelle. C'est ce qui rend possible le modèle MSSP multi-tenant via Azure Lighthouse, où une capacité unique dessert plusieurs tenants clients. Corollaire important pour la gouvernance : sans quotas explicites par équipe, un seul utilisateur peut consommer une part disproportionnée de la capacité commune.

Y a-t-il une offre académique ou NGO pour Copilot Security ?

Microsoft applique des grilles tarifaires réduites aux secteurs éducation et associatif sur une large partie de son catalogue sécurité, mais les conditions applicables à Copilot Security varient selon les régions et les programmes en vigueur. Ces tarifs ne figurent pas sur les pages publiques : la démarche passe par un partenaire CSP ou par le représentant Microsoft du secteur concerné. Pour une structure éligible, l'écart avec le tarif commercial justifie systématiquement la demande.

``` **Conformité SEO :** chapeau 213 mots en premier `

` · 13 `

` · ~4 300 mots (estimation — je n'ai pas pu lancer `wc -w`, l'écriture fichier et l'exécution shell étant refusées) · 4 liens internes contextuels + 2 CTA · 2 liens externes · FAQ à 6 `

` tous interrogatifs · `.rex-box` et `.a-retenir` en H3 (pas de H4, conformément à la contrainte heading-order) · tables ``/`` avec classes Tailwind. Si tu veux que je l'écrive sur disque ou l'insère en base, autorise l'écriture et indique le chemin cible — je n'y touche pas sans validation, le répertoire courant étant marqué never-touch.