Microsoft Sentinel : prix 2026, fonctionnement et pièges du SIEM cloud

⚡ Key Takeaways

• Microsoft Sentinel est le SIEM (Security Information and Event Management) cloud-native de Microsoft, facturé au volume de logs ingérés. Le prix au Go dépend de la région Azure et du mode d'achat (paiement à l'usage ou palier d'engagement) : il se vérifie sur l'estimateur de Microsoft.
• Un SI mal configuré peut ingérer des centaines de Go de logs par jour, dont une grande partie ne sert jamais à la détection. La maîtrise de l'ingestion est donc le premier sujet.
• 3 leviers pour maîtriser le coût : filtrage en amont (Logstash, Cribl, Azure Data Collection Rules), tiering (Data Lake pour les logs volumineux à conserver à moindre coût), choix sélectif des connecteurs.
• Sentinel managé par un prestataire : le coût dépend du volume de logs et du niveau de service attendu. À comparer avec le coût d'une équipe interne formée à KQL.

Microsoft Sentinel is Microsoft's cloud-native SIEM (Security Information and Event Management), merged with SOAR (Security Orchestration, Automation and Response) and UEBA (User and Entity Behavior Analytics) capabilities. Launched in 2019 as Azure Sentinel, repositioned in 2024 within the Microsoft Defender portal, Sentinel collects, analyzes and correlates cloud-scale security logs to detect threats, intrusions and anomalous behavior.

Le pitch commercial : "SIEM illimité, élasticité cloud, IA intégrée, tarification simple au Go". La réalité terrain : facture mensuelle imprévisible si l'ingestion n'est pas maîtrisée, courbe d'apprentissage KQL (Kusto Query Language) abrupte, et un piège pricing où les logs réseau verbeux peuvent coûter très cher alors que leur valeur détection est quasi nulle.

Entre Splunk (licensing rigide, installation lourde) et Sentinel vendu comme "flexible et économique", le choix semble évident. Mais une ingestion mal optimisée peut faire perdre à Sentinel son avantage de coût. Cet article expose le vrai coût de Sentinel, compare objectivement avec Splunk/QRadar, explique comment éviter la dérive de facture, et surtout calcule si votre organisation a réellement besoin d'un SIEM ou si un EDR + logs centralisés suffit.

‍

What is Microsoft Sentinel and how does it really work?

‍

Architecture and positioning

Sentinel is not software to be installed, but an Azure SaaS service based on three components:

Azure Monitor Log Analytics Workspace: storage backend. All logs ingested into Sentinel transit and are indexed in Log Analytics. Herein lies the pricing confusion: you pay for Log Analytics + Sentinel as combined third parties (simplified since 2023), but there are additional costs (retention, archiving, restoration).

Moteur de corrélation et analytics : règles de détection écrites en KQL (Kusto Query Language, le SQL de Microsoft). Sentinel embarque de nombreux modèles de règles pré-configurées (attaques MITRE ATT&CK, comportements anormaux, indicateurs de compromission) + possibilité de créer des règles custom. Machine learning intégré pour détecter les anomalies (connexions depuis une géolocalisation inhabituelle, pic d'activité utilisateur à 3h du matin).

SOAR et automatisation : playbooks basés sur Azure Logic Apps. Quand une alerte se déclenche (ex : tentative bruteforce RDP), un playbook peut automatiquement bloquer l'IP dans le firewall, créer un ticket ServiceNow, envoyer une notification Teams au SOC. Une partie des réponses de niveau 1 peut ainsi être automatisée.

Defender XDR Integration: Starting in 2024, Sentinel will run within the Microsoft Defender portal. Integration with Defender for Endpoint, Defender for Cloud, and Defender for Identity. Unified view: endpoints, identity, cloud, and on-premises in a single pane of glass.

‍

Third-party data: Analytics vs. Data Lake

Analytics tier : logs haute valeur (authentifications, alertes EDR, threat intelligence). Analyse temps réel, corrélation, détection. Rétention 90 jours gratuite. Facturation à l'ingestion (Pay-As-You-Go) ou en commitment tier à partir de 100 Go/jour (50 Go/jour en préversion). Le tarif au Go varie fortement selon la région : vérifiez le calculateur Azure pour West Europe.

Data Lake tier : stockage long terme pour les logs volumineux à faible valeur (firewall verbeux, proxy web, network flow), nettement moins cher que l'Analytics tier. Facturé à l'ingestion + traitement + rétention (ce n'est pas gratuit). Usage : forensic, compliance, requêtes occasionnelles. Pas de détection temps réel.

Optimal approach: ingest Windows Security Events, Microsoft Entra ID logs, and EDR alerts into the analytics tier; route verbose firewall logs (e.g., 50 GB/day) to the data lake. At these volumes, the price difference per GB between the two tiers drastically reduces the cost without any loss of detection capability (network logs almost never trigger real-time alerts).

‍

Connectors and data sources

Native Microsoft connectors (free to ingest):

• Azure Activity Logs (Azure resource auditing)
• Microsoft 365 Audit Logs (Exchange, SharePoint, Teams)
• Microsoft Defender for Endpoint
• Microsoft Entra ID Identity Protection (formerly Azure AD)
• Office 365 Advanced Threat Protection

Avec licence M365 E5/A5/F5/G5 : data grant jusqu'à 5 Mo/user/jour. À titre d'exemple, organisation de 1000 users = jusqu'à 5 Go/jour gratuits pour les logs Microsoft 365 éligibles.

Avec Defender for Servers P2 : 500 Mo/serveur/jour gratuits pour certains logs de sécurité serveurs (allocation mutualisée à l'échelle de l'abonnement).

Third-party connectors (chargeable):

• Firewalls (Palo Alto, Fortinet, Checkpoint) via Syslog/CEF
• Proxies (Zscaler, Cisco Umbrella)
• Third-party EDR (CrowdStrike, SentinelOne) via API
• Cloud providers (AWS CloudTrail, GCP Audit)
• Legacy SIEM (Splunk, QRadar) for gradual migration

Pièges connecteurs : certains envoient des logs ultra-verbeux. Un firewall non filtré génère un gros volume de logs de trafic autorisé inutile. Filtrer au niveau du collecteur (deny logs only) réduit fortement ce volume.

‍

KQL: the language that makes or breaks your experience

Kusto Query Language = an SQL-like language for querying logs. Syntax:

kusto

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625 // Failed logon
| summarize FailedAttempts = count() by Account, Computer
| where FailedAttempts > 10
| order by FailedAttempts desc

Courbe d'apprentissage : rapide pour les requêtes simples, plus longue pour maîtriser les agrégations complexes (join, union, parse). Obligatoire pour créer des règles custom, tuner les faux positifs, investiguer les incidents.

SPL (Splunk) Comparison: KQL is simpler for basic queries but less powerful for advanced transformations. Splunk SPL offers more built-in functions and better community documentation.

‍

Pricing réel et calcul de coût : le piège de l'ingestion

‍

2026 Rate Structure

Depuis 2025, Sentinel s'organise autour de deux tiers : l'Analytics tier (détection temps réel, requêtes, alertes, hunting : le tier « complet ») et le Data Lake tier (stockage long terme à bas coût pour les logs volumineux et peu interrogés). Le bon réflexe budgétaire n'est pas de négocier le prix au Go, mais de décider quel log atterrit dans quel tier.

Analytics tier (Pay-As-You-Go) : La facturation combine deux compteurs : l'ingestion Log Analytics + une surcharge d'analyse Sentinel. Le tarif PAYG varie selon la région. Pour West Europe, vérifiez le tarif exact sur l'estimateur Microsoft ou le calculateur Azure : les anciens montants en euros correspondent à l'ancien modèle de facturation et ne sont plus fiables.

Please note: The Sentinel surcharge does not apply to ingested Auxiliary logs or Basic logs.

Analytics tier (Commitment tiers, réservation de capacité) : Vous réservez un volume quotidien à tarif réduit, de 100 Go/jour jusqu'à 50 000 Go/jour. Microsoft annonce des économies jusqu'à 52 % vs PAYG sur les tiers les plus élevés. Deux règles à retenir :

• Tout dépassement au-dessus du volume réservé est facturé au tarif réduit du commitment tier (pas au tarif PAYG plein) : c'est un avantage majeur.
• À l'inverse, la capacité réservée non consommée n'est pas remboursée : sur-réserver coûte cher. Le commitment tier peut être relevé à tout moment, mais abaissé seulement tous les 31 jours.

Palier 50 Go/jour (préversion) : Microsoft propose en préversion publique un palier d'engagement de 50 Go/jour, qui comble le trou entre le paiement à l'usage et le minimum historique de 100 Go. Le tarif promotionnel s'applique du 1er octobre 2025 au 31 décembre 2026 ; les clients qui souscrivent pendant cette période le conservent jusqu'au 31 mars 2027. Le prix varie selon la région.

Data Lake tier : stockage à bas coût pour les sources verbeuses (firewall, flux réseau, proxy, DNS). Attention : le Data Lake n'est pas gratuit : il est facturé à l'ingestion + au traitement + à la rétention. Contrepartie : ces logs ne déclenchent pas de règles d'analyse temps réel ni d'alertes ; ils restent interrogeables via KQL et notebooks pour le forensic et la conformité.

Retention and archiving:

• Analytics tier: 90-day interactive retention by default, extendable up to 2 years (retention beyond the default period is billed separately).
• Rétention long terme (ex-Archive) : facturée au Go stocké par mois, à un tarif bien inférieur à la rétention Analytics.
• Search Job sur les données long terme : facturé au Go scanné (forensic à la demande).
• Data Restore (Archive → Analytics): billed per GB and moved to the hot tier.

Additional costs that are often overlooked:

• Azure Logic Apps (SOAR playbooks): billed per action; negligible for low volumes.
• Outbound bandwidth: Exporting logs to a third-party tool = Azure Egress billing (first GB free, then standard Azure rates).

Realistic monthly cost estimate

The amounts below are approximate: the exact price depends on your Azure region and billing model. Be sure to recalculate using the Azure calculator before making any commitments.

Scénario PME 200 employés, hybride cloud (volumes à titre d'exemple) :

• Windows Event Logs (50 servers): 2 GB/day
• Azure AD Sign-ins: 1 GB/day (included free of charge E5)
• Microsoft 365 Audit: 1.5 GB/day (included free of charge in E5)
• Defender for Endpoint: 3 GB/day (included free with Defender for Servers)
• Fortinet firewall: 15 GB/day (filtered, deny only)
• Zscaler proxy: 5 GB/day
• Total Analytics tier: ~27.5 GB/day

Conclusion: At this volume, the 100 GB/day Tier 100 plan would be a waste (72.5 GB/day reserved but unused). Stick with Pay-As-You-Go, and switch the verbose firewall to Data Lake if you enable it in full mode. The new 50 GB/day promotional tier may also be a good option at this ingestion level.

Scénario entreprise 2000 employés, multicloud (volumes à titre d'exemple) :

• Server logs (300 VMs): 30 GB/day
• Azure + AWS + GCP audit logs: 20 GB/day
• Multi-platform EDR: 40 GB/day
• Network logs (firewalls, IDS/IPS): 200 GB/day → Data Lake
• Proxy and DNS: 50 GB/day → switch to Data Lake
• Analytics tier: ~90 GB/day
• Data Lake tier: ~250 GB/day

The issue isn't the cost per GB, but rather the filtering: sending 340 GB/day to Analytics would result in a massive bill, whereas routing 250 GB/day to the Data Lake drastically reduces the total cost without compromising detection capabilities (network and proxy logs almost never trigger real-time alerts).

Scénario cauchemar (ingestion non optimisée, volumes à titre d'exemple) :

• Firewall logs ALL traffic (authorized + deny): 500 GB/day
• Unfiltered debug application logs: 200 GB/day
• Duplicate logs (sent from 2 sources): 100 GB/day
• Total: 800 GB/day, all in the Analytics tier

À ce volume, sans gouvernance, la facture mensuelle devient considérable pour un bruit que personne ne regarde. Leçon : filtrer à la source, router les sources verbeuses vers le Data Lake, surveiller l'ingestion quotidienne. Sentinel sans gouvernance = gouffre financier.

Free trials and data grants

31-day trial: 10 GB/day free per workspace (Log Analytics ingestion and Sentinel analysis waived), limited to 20 workspaces per tenant. Perfect for a POC.

Data grants Microsoft 365 E5 : certaines sources Microsoft sont ingérées gratuitement quel que soit le commitment tier (jusqu'à 5 Mo/user/jour), ce qui réduit d'autant la part payante du volume de logs.

Data grants Defender for Servers P2: free ingestion quota per protected VM, which significantly reduces costs for large server fleets.

Strategy: Maximize free data allowances, route verbose data sources to the data lake, and reserve a commitment tier only for the actual volume of paid Analytics data consumed.

Sentinel vs Splunk vs QRadar: battle of the SIEM giants

‍

Splunk Enterprise Security: the flexible behemoth

Strengths:

• SPL (Search Processing Language): the most powerful of SIEM query languages
• Large catalogue d'apps Splunkbase (intégrations community)
• On-premise, cloud, hybrid: deployment everywhere
• Risk-Based Alerting (RBA) : réduit le volume d'alertes via un scoring de risque cumulatif
• Native MITRE ATT&CK aligned detection

Weaknesses:

• Coût élevé : licensing à l'ingestion ou workload pricing complexe
• Heavy infrastructure: indexers, search heads, forwarders to manage (except Splunk Cloud)
• Steep SPL learning curve (but massive community)

Pricing Splunk:

• Sur devis : licence + infrastructure (sauf Splunk Cloud)
• Sur Sentinel, pour une volumétrie de 200 Go/jour : prix à calculer sur l'estimateur Azure. À 200 Go/jour, un palier d'engagement s'applique, avec une économie annoncée par Microsoft allant jusqu'à 52 % par rapport au paiement à l'usage.

Quand choisir Splunk : si stack hétérogène (multi-vendor, legacy on-prem), besoin SPL avancé, budget conséquent, équipe SOC experte Splunk.

IBM QRadar SIEM: the structured veteran

Strengths:

• Licensing EPS (Events Per Second): predictable (but rigid)
• Correlation engine mature (offense ranking)
• Strong compliance (finance, government)
• Support for physical appliances (sovereign datacenters)

Weaknesses:

• Monolithic architecture (difficult scaling)
• Aging UX (slow improvements)
• Intégrations moins nombreuses que Splunk
• Weak cloud-native (late catch-up)

Pricing QRadar:

• Sur devis : licensing EPS + appliance éventuelle

When to choose QRadar: regulated environments (banking, OIV), sovereign on-premise requirements, EPS licensing preferred for large volumes.

‍

SIEM Comparison 2026

‍

‍

Objective verdict:

• Sentinel: unbeatable for Microsoft-first organizations (Azure, M365), provided you keep costs under control using data grants and effectively manage cloud elasticity.
• Splunk : leader fonctionnel, taillé pour les environnements hétérogènes complexes, budgets conséquents, avec une expertise SPL disponible en interne.
• QRadar : historiquement positionné sur les secteurs ultra-régulés et le licensing EPS, avec une infrastructure on-premise souveraine, mais son avenir est à surveiller depuis la reprise de l'activité QRadar par Palo Alto.

‍

Les vrais cas d'usage et leur valeur

‍

Use Case 1: Identity Compromise Detection (Microsoft Entra ID)

Background: An attacker steals an employee’s credentials via phishing. A login attempt was made from an IP address in Russia at 2 a.m.

Sentinel Detection:

• Analytics rule: Entra ID login from an unusual country + at an unusual time
• UEBA : le score de risque de l'utilisateur passe en risque élevé
• Alerte générée en quasi temps réel
• Auto Playbook: Revoke the session, force MFA re-authentication, notify the manager and the SOC

Sans SIEM : détection manuelle via revue quotidienne des logs Entra ID (si elle est faite) = détection tardive. L'attaquant exfiltre des emails, accède à du SharePoint sensible.

Enjeu : un incident évité ou contenu rapidement, avec moins de forensics, de perte de propriété intellectuelle et de risque de notification RGPD.

‍

Use Case 2: Ransomware Detection and Propagation

Background: Ransomware infects a user's computer and begins encrypting the network via SMB.

Sentinel Detection:

• Defender for Endpoint alert: suspicious behavior (mass encryption)
• Sentinel Correlation: The same user accessed 50+ servers in 10 minutes (abnormal)
• Network logs: spike in outbound SMB traffic from the infected computer
• Merger Alert: Ransomware Outbreak Underway
• Playbook: Isolate the workstation, lock the AD account, take a snapshot of critical VMs

Résultat : la propagation est détectée et contenue rapidement, l'impact reste limité à quelques serveurs.

Sans SIEM : détection tardive (les utilisateurs signalent des fichiers chiffrés), propagation à une large partie du parc, avec downtime, recovery et rançon potentielle.

‍

Use Case 3: Compliance and Auditing (GDPR, ISO 27001)

Background: An ISO 27001 audit requires evidence that access to personal data is monitored.

Sentinel:

• Tracking of all access to the customer SQL database (query audit logs)
• Alerts for access outside of business hours (10 p.m.–6 a.m.)
• Monthly reporting: who accessed what, when
• 13-month retention period (compliance)

Audit ISO : l'auditeur demande "montrez-moi les accès à la base clients sur 12 mois". Sentinel : rapport généré par une simple requête KQL.

Sans SIEM : logs dispersés (SQL Server, application, AD). Agrégation manuelle longue (temps ingénieur). Risque de non-conformité si les logs sont incomplets.

Gain : temps d'audit réduit + couverture du risque de non-conformité (amendes potentielles).

‍

Use cases with zero value: unnecessary over-ingestion

Anti-pattern: ingest ALL logs from ALL systems "just in case".

Exemple illustratif : une entreprise ingère :

• Verbose IIS logs (every HTTP 200 OK): 300 GB/day
• Application debug logs: 150 GB/day
• DNS query logs (all queries): 200 GB/day
• Total: 650 GB/day, all in the Analytics tier

À ce volume, la facture mensuelle devient considérable, alors qu'une infime partie de ces logs déclenche des alertes. Le reste est du bruit inutile.

Optimization:

• IIS: Log only 4xx/5xx errors = 300 GB → 5 GB
• App debug: disable in prod, enable on-demand = 150 GB → 0 GB
• DNS: Log only rejected requests = 200 GB → 3 GB

Après optimisation, dans cet exemple : ~8 Go/jour, sans aucune perte de capacité de détection.

‍

Deployment and pitfalls to avoid

‍

Mistake 1: Deploying without an ingestion strategy

Problème : activer tous les connecteurs "pour voir". La facture s'envole dès les premiers mois.

Best practice:

• Identify 5–10 critical log sources (AD, EDR, critical firewalls)
• Calculate the expected volume (7-day pilot monitoring)
• Définir un budget mensuel maximal pour Sentinel avant d'activer les connecteurs
• Roll out gradually; measure ROI by source

‍

Mistake 2: Neglecting M365/Defender data grants

Problem: Paying for Microsoft log ingestion when it is free with existing licenses.

Vérification : avez-vous des licences M365 E5 ou Defender for Servers P2 ? Activez les data grants. Ces grants réduisent directement la part payante de l'ingestion.

‍

Mistake 3: Unoptimized Analytics Rules

Problème : les règles Microsoft par défaut, non ajustées, génèrent un grand nombre d'alertes, dont beaucoup de faux positifs. SOC submergé, vraies menaces noyées.

Required tuning:

• 1st month: audit mode, no alerting
• Analyze false positive patterns
• Adjust the thresholds (e.g., 10 failed logins → 50 if legacy apps generate a lot of false positives)
• Whitelist of known IP addresses/users

Résultat : beaucoup moins d'alertes, et une bien meilleure proportion de vrais positifs.

‍

Mistake 4: Neglecting retention and archiving

Problem: Compliance requires 12 months of logs. Analytics data retention is free for 90 days, after which it is billed separately.

Calculation: Retaining 100 GB per day for an additional 9 months in Extended Analytics retention is much more expensive than switching to Archive.

Solution : après 90 jours, basculer en rétention long terme (ex-Archive, ou Data Lake) au lieu de la rétention Analytics étendue. Le Search Job, facturé au Go scanné, rend l'accès forensic abordable à la demande.

‍

Mistake 5: Underestimating KQL skills

Problème : le SOC ne maîtrise pas KQL. Incidents mal investigués, MTTR (Mean Time To Respond) qui s'allonge.

Required education:

• 3-day KQL Basics course (Microsoft Learn, free)
• 2 weeks of investigative practice (labs)
• SC-200 certification (Microsoft Security Operations Analyst)

Alternative : externaliser le SOC (Managed Sentinel). Coût : sur devis, selon le volume de logs et le SLA. Pertinent si l'équipe SOC interne est réduite.

Si vous n’avez pas ces compétences en interne, le tri des alertes et l’investigation peuvent être confiés à un tiers. C’est ce que propose l’offre SOC managé d’IT Systèmes : une surveillance 24 h/24 et 7 j/7 assurée par un SOC partenaire, piloté par IT Systèmes.

‍

Sentinel: investment or trap?

Microsoft Sentinel is neither the budget-friendly cloud SIEM that marketing hype promises, nor a pricing scam. It is a powerful tool for Microsoft-centric organizations that prioritize data ingestion discipline.

Sentinel makes sense if:

• Dominant Microsoft stack (Azure, M365, Defender)
• Data grants actifs (E5, Defender for Servers) = facture réduite dès le départ
• Volumétrie maîtrisée et optimisée (Analytics + Data Lake)
• Available KQL skills or Managed SIEM budget
• Need for scalability (temporary spikes in traffic, rapid scaling)

Sentinel is a trap if:

• Uncontrolled ingestion (any logger without filter)
• Multi-vendor heterogeneous stack (Splunk better)
• Forte volumétrie mal optimisée (coût explosif)
• No KQL (learning curve)
• 100% on-premise sovereign environment (QRadar/Splunk better)

Valeur réaliste :

• Investissement : variable selon la volumétrie ingérée en Analytics tier
• Gains : incidents majeurs détectés et contenus plus tôt, compliance facilitée, automatisation d'une partie du niveau 1
• Rentabilité : réelle si l'ingestion est optimisée, inexistante en cas de dérive volumétrique

‍

The real question: Do you need a SIEM?

You do NOT need SIEM if:

• Petite structure, infrastructure simple (cloud SaaS uniquement)
• A modern EDR solution is sufficient (Defender for Endpoint, CrowdStrike)
• Basic centralized logs are sufficient (Azure Monitor, CloudWatch)
• No strict compliance requirements

You NEED SIEM if:

• Organisation de taille moyenne ou plus, infrastructure hybride/complexe
• Regulated compliance (ISO 27001, NIS2, PCI-DSS)
• Dedicated SOC team or outsourcing
• Critical multi-source correlation (not just EDR)

Alternative plus légère : si vous n'avez pas besoin d'un SIEM complet, Microsoft Defender XDR (sans Sentinel) + logs centralisés Azure Monitor, pour un budget généralement plus faible qu'un déploiement Sentinel.

Next pragmatic steps:

1. Audit the current stack: Which logs are critical? What is the expected volume?
2. Activate the 31-day Sentinel trial: Proof of concept on 3–5 priority sources
3. Calculate the actual cost: PAYG vs. Commitment vs. Data Lake, including data grants
4. Testing detection rules: false positives? Genuine alerts? Need for fine-tuning?
5. Team size at KQL: at least 2 people (skill redundancy)
6. Decide: Sentinel Full, Defender XDR only, or Splunk/QRadar if it's a better fit

Erreur fatale : déployer Sentinel sans gouvernance d'ingestion ni compétences KQL = facture qui explose pour aucune valeur de détection. Succès : stratégie ciblée, ingestion optimisée, tuning continu = détection efficace et coûts maîtrisés.

Microsoft Sentinel est un excellent SIEM cloud pour qui sait l'utiliser. Pour les autres, c'est un gouffre financier qui ne détecte pas plus de menaces qu'un outillage basique bien moins cher. Choisissez en connaissance de cause.

Un SIEM ne protège que si quelqu’un exploite ses alertes. L’offre SOC managé et MDR d’IT Systèmes assure ce suivi en continu pour les PME et ETI.

‍