Pourquoi le CASB est devenu incontournable
En quelques années, les données de l'entreprise ont quitté les murs du SI. Elles vivent désormais dans Microsoft 365, Salesforce, Google Workspace, Notion, Slack, ChatGPT… et dans de nombreuses applications que la DSI n'a parfois même pas validées.
Résultat : les outils de sécurité historiques (pare-feu, antivirus, DLP réseau) ne voient plus grand-chose. Ils savent qu'un poste se connecte à un service cloud, mais pas quel utilisateur fait quoi, avec quelle donnée, dans quelle application.
C'est précisément le rôle du CASB (Cloud Access Security Broker) : remettre de la visibilité et du contrôle là où le cloud a effacé les frontières.
En quelques années, les données de l'entreprise ont quitté les murs du SI. Elles vivent désormais dans Microsoft 365, Salesforce, Google Workspace, Notion, Slack, ChatGPT… et dans de nombreuses applications que la DSI n'a parfois même pas validées.
Résultat : les outils de sécurité historiques (pare-feu, antivirus, DLP réseau) ne voient plus grand-chose. Ils savent qu'un poste se connecte à un service cloud, mais pas quel utilisateur fait quoi, avec quelle donnée, dans quelle application.
C'est précisément le rôle du CASB (Cloud Access Security Broker) : remettre de la visibilité et du contrôle là où le cloud a effacé les frontières.
Le CASB en une phrase
- Le pare-feu décide qui peut entrer et sortir du réseau.
- La DLP inspecte le contenu des données pour empêcher les fuites.
- Le CASB comprend les applications cloud elles-mêmes — leurs API, leurs utilisateurs, leurs partages — et applique des règles métier adaptées à chacune.
C'est la brique qui sait parler SaaS, là où les autres ne voient que du trafic chiffré vers un domaine inconnu.
Les 4 piliers du CASB
Le cabinet Gartner a posé un cadre devenu une référence. Un bon CASB couvre quatre piliers :
1. Visibilité
Découvrir les applications cloud utilisées, y compris celles non validées par la DSI (Shadow IT), et les classer selon une typologie classique : sanctionnées (officielles, sous contrat), tolérées (utilisées mais non officielles) et interdites (à bloquer). Cette cartographie est continue, pas ponctuelle : de nouvelles apps apparaissent chaque semaine, certaines évoluent en risque (changement de propriétaire, fuite documentée, modification des CGU). Sans ce socle, aucune politique de sécurité cloud n'est crédible.
2. Conformité
Vérifier que les usages cloud respectent les cadres réglementaires applicables : RGPD (Europe), HIPAA (santé US), PCI-DSS (paiements), ISO 27001 (norme internationale), DORA (acteurs financiers UE, en application depuis le 17 janvier 2025), NIS2 (directive UE 2022/2555 élargissant la cybersécurité aux entités « essentielles » et « importantes » dans une vingtaine de secteurs).
Concrètement, comment le CASB aide :
-
Pour DORA : journalisation et reporting des incidents SaaS, cartographie des prestataires TIC critiques utilisés.
-
Pour NIS2 : détection et notification des incidents (obligation de signalement sous 24h), inventaire continu des actifs SaaS, preuves d'audit pour la responsabilité personnelle des dirigeants.
-
Pour le RGPD : aide aux DPIA, gestion des transferts internationaux, contrôle des partages externes de données personnelles.
3. Sécurité des données
Empêcher les fuites, contrôler les partages externes, classer les données sensibles, étendre les règles DLP aux environnements SaaS — y compris quand la donnée est créée directement dans le cloud (Google Docs, Slack).
4. Protection contre les menaces
Détecter les comptes compromis, les ransomwares qui infectent SharePoint ou Google Drive. L'UEBA (User and Entity Behavior Analytics) joue un rôle transversal : à la fois détection de menaces (connexion impossible depuis deux pays en 5 minutes) et DLP comportementale (un utilisateur télécharge dix fois son volume habituel avant son préavis).
Empêcher les fuites, contrôler les partages externes, classer les données sensibles, étendre les règles DLP aux environnements SaaS — y compris quand la donnée est créée directement dans le cloud (Google Docs, Slack).
4. Protection contre les menaces
Détecter les comptes compromis, les ransomwares qui infectent SharePoint ou Google Drive. L'UEBA (User and Entity Behavior Analytics) joue un rôle transversal : à la fois détection de menaces (connexion impossible depuis deux pays en 5 minutes) et DLP comportementale (un utilisateur télécharge dix fois son volume habituel avant son préavis).
Comment ça marche, concrètement ?
Un CASB peut se déployer de trois manières, souvent combinées :
1. Mode API (out-of-band)
Connexion directe aux APIs des services cloud (M365, Google Workspace, Salesforce…) pour scanner les données déjà présentes. Simple, sans agent — mais non temps réel : une donnée peut être exfiltrée pendant le délai qui sépare l'action de son scan.
2. Mode Proxy (inline)
Deux sous-modes très différents :
-
Forward proxy : trafic routé via le CASB par un agent endpoint ou un fichier PAC. Couvre Shadow IT et apps sanctionnées sur postes managés. Nécessite un agent.
-
Reverse proxy : trafic redirigé vers le CASB via l'IdP (SAML avec Azure AD, Okta…), sans agent. Idéal pour BYOD, prestataires, terminaux non managés. Point sensible : fragile aux changements d'interface des éditeurs SaaS (URL, JavaScript) — une mise à jour Microsoft ou Salesforce peut casser des politiques. La tendance lourde du marché est donc forward proxy + API. Le reverse proxy garde sa pertinence sur un cas précis : BYOD et sous-traitants — raison pour laquelle des acteurs comme Skyhigh y restent fortement investis.
3. Mode Discovery (log-based)
Analyse passive des logs du pare-feu ou du proxy pour cartographier le Shadow IT.
Analyse passive des logs du pare-feu ou du proxy pour cartographier le Shadow IT.
Le sujet brûlant 2026 : la GenAI
Deux angles à distinguer, souvent confondus :
La Shadow AI — usage d'applications GenAI grand public (ChatGPT, Gemini, Claude.ai, Perplexity, Copilot gratuit…) par les collaborateurs sans validation IT. Un employé colle un extrait de contrat client dans ChatGPT pour le résumer. Sans CASB, l'action passe inaperçue. Avec un CASB moderne, l'application est identifiée, le contenu inspecté, la donnée sensible masquée ou bloquée.
L'AI sanctionnée — Microsoft 365 Copilot, ChatGPT Enterprise, Claude for Work, Gemini Enterprise… L'enjeu n'est plus le blocage, mais le contrôle des usages internes : qui peut utiliser quel modèle ? Avec quelles données ? Les prompts sont-ils journalisés ? Y a-t-il des fuites entre départements via Copilot qui voit « trop » de fichiers SharePoint ?
Le risque souvent oublié : les apps OAuth tierces
L'un des angles morts majeurs du SaaS moderne. Quand un utilisateur clique sur « Se connecter avec Google » ou « Autoriser l'accès à votre compte Microsoft » pour une application tierce, il accorde des tokens OAuth qui peuvent rester valides des mois, parfois des années. Plusieurs incidents marquants de 2023-2024 (compromissions de tenants M365, attaques sur des chaînes d'approvisionnement SaaS) ont exploité ces tokens plutôt que des mots de passe.
Les CASB modernes — et plus encore les SSPM — savent désormais :
-
Inventorier toutes les applications OAuth connectées à un tenant,
-
Scorer leur risque (éditeur, périmètre des permissions, popularité),
-
Révoquer des tokens à grande échelle,
-
Détecter les apps malveillantes ou compromises (consent phishing).
Pour un RSSI en 2026, cette capacité est devenue un critère de sélection à part entière.
L'écosystème autour du CASB
Le CASB ne vit pas seul. Plusieurs catégories cousines :
L'écosystème autour du CASB
Le CASB ne vit pas seul. Plusieurs catégories cousines :
-
SSPM (SaaS Security Posture Management) — configuration des SaaS : MFA admin, partages publics oubliés, OAuth tiers permissifs.
-
CSPM (Cloud Security Posture Management) — équivalent pour IaaS/PaaS (AWS, Azure, GCP) : buckets S3 publics, IAM trop permissif.
-
DSPM (Data Security Posture Management) — la donnée elle-même : où, qui, classification, protection.
- CNAPP (Cloud-Native Application Protection Platform) — agrège CSPM + CWPP + parfois DSPM, pour Kubernetes/conteneurs/serverless.
Schéma mental :
-
CASB → usage des SaaS
-
SSPM → config des SaaS
-
CSPM/CNAPP → infrastructure cloud
-
DSPM → la donnée, partout
Le SSPM existe aussi en pure-play, indépendamment des CASB. Trois acteurs emblématiques avec des positionnements distincts :
-
Adaptive Shield (racheté par CrowdStrike en novembre 2024, intégré à la plateforme Falcon) — historiquement axé sur l'identity-first SSPM, forte couverture multi-SaaS.
-
AppOmni — orienté grandes entreprises et applications custom, fort sur Salesforce, Workday, ServiceNow.
-
Obsidian Security — orienté threat detection SaaS-to-SaaS, identification de chaînes d'attaques traversant plusieurs apps.
Tendance 2026 à connaître : la convergence vers des plateformes « data security » unifiées qui rendent floue la frontière historique entre CASB, DLP cloud et DSPM. Microsoft Purview, Netskope, Palo Alto et Forcepoint poussent tous dans cette direction. À moyen terme, « CASB », « DLP » et « DSPM » pourraient devenir des modules d'une seule plateforme plutôt que des produits distincts. Cas emblématique : Microsoft Purview, qui regroupe désormais DLP, DSPM, Insider Risk Management, AI Hub, records management et Defender for Cloud Apps dans une plateforme unifiée. Pour les organisations Microsoft-centric, c'est devenu un choix structurant — non plus « un CASB parmi d'autres » mais la plateforme data security de l'écosystème.
Horizon 2026-2027 : l'IA agentique et les identités non-humaines
Sujet émergent qui va structurer le marché dans les 18 prochains mois. Les agents IA — qui agissent au nom de l'utilisateur via OAuth, API, ou des protocoles comme MCP (Model Context Protocol, standard récent permettant aux agents IA de se connecter à des sources de données et outils externes) — créent une nouvelle classe d'identités non-humaines (NHI — Non-Human Identities) à gouverner.
Un agent Copilot, un agent Salesforce, un agent custom branché sur 12 SaaS via OAuth — chacun accède aux données, déclenche des actions, prend des décisions… avec des permissions souvent excessives. Les éditeurs (Netskope, Palo Alto, CrowdStrike via Adaptive Shield, Microsoft Purview) communiquent activement en 2026 sur la gouvernance des NHI : inventaire, scoring de risque, révocation, détection d'agents compromis.
Pour les architectes sécurité, c'est probablement le critère de différenciation des plateformes SSE en 2027.
Intégration au SOC : logs, SIEM, SOAR
Un CASB génère des volumes considérables de logs : événements API, alertes UEBA, partages, téléchargements, accès admin, anomalies. Ces logs n'ont de valeur qu'exploités.
Trois bonnes pratiques :
-
Centralisation dans le SIEM (Splunk, Microsoft Sentinel, Elastic, QRadar, Chronicle…) pour corréler les événements CASB avec EDR, IdP, pare-feu et réseau.
-
Playbooks SOAR (XSOAR, Splunk SOAR, Tines, Torq…) pour automatiser les réponses : révocation de session, désactivation de compte, isolation d'un poste, blocage d'un partage public.
-
Dashboards exécutifs : volume de Shadow IT, top 10 apps risquées, incidents par catégorie réglementaire (NIS2, RGPD…).
Sans cette boucle log → analyse → action, un CASB devient une source d'alertes inertes, et la fatigue du SOC s'installe.
⚠️ Ce que le CASB ne fait pas (ou mal)
⚠️ Ce que le CASB ne fait pas (ou mal)
-
Applications non répertoriées dans son catalogue — angle mort possible.
-
Mode proxy : latence si mal dimensionné, fragilité du reverse proxy aux changements d'UI.
-
Apps mobiles natives : contournement par certificate pinning.
-
Chiffrement de bout en bout : visibilité limitée.
-
Faux positifs : saturation du SOC si règles non affinées.
-
Performance et géographie : quand tout le trafic passe par un cloud de sécurité, la densité des PoPs (Points of Presence) et leur proximité avec les utilisateurs deviennent critiques. Un PoP mal placé ajoute 50 à 200 ms de latence et dégrade l'UX sur les apps interactives (Teams, Salesforce, visio). À mesurer en PoC.
Bonne pratique : démarrer en mode audit, affiner, puis passer en mode actif progressivement.
Un projet CASB est un projet de gouvernance déguisé en projet technique
Un projet CASB échoue rarement à cause de la technologie. Il échoue à cause de l'organisation :
Un projet CASB est un projet de gouvernance déguisé en projet technique
Un projet CASB échoue rarement à cause de la technologie. Il échoue à cause de l'organisation :
-
Catalogue applicatif officiel : qui décide qu'une app est sanctionnée, tolérée ou interdite ? Sans instance claire (comité DSI + RSSI + métiers + DPO), le CASB n'a pas de légitimité.
-
Process de demande d'apps par les métiers : sinon, ils contournent.
-
Conflits DSI / métiers : bloquer un outil utilisé depuis des années sans préavis = friction garantie.
-
DPO et juridique : le CASB inspecte des contenus, parfois personnels. Le cadre de protection des données (information des salariés, proportionnalité, durée de conservation des logs) doit être posé avant déploiement.
-
Sponsoring exécutif : sans portage COMEX, le projet stagne.
Sans gouvernance, le meilleur CASB du marché devient une étagère.
Souveraineté et extra-territorialité
Sujet montant en 2025-2026, particulièrement en Europe, mais qui concerne toute organisation traitant des données sensibles hors de sa juridiction d'origine. Tous les CASB majeurs sont américains (Netskope, Zscaler, Palo Alto, Microsoft, Cisco, Forcepoint, Skyhigh), ce qui les place sous le Cloud Act et le FISA 702 — lois autorisant les autorités américaines à requérir des données détenues par des entreprises US, où qu'elles soient hébergées.
Différents pays ont mis en place des cadres pour qualifier des offres cloud « souveraines » ou « de confiance » :
-
France : qualification SecNumCloud de l'ANSSI, obligatoire pour les administrations sur données sensibles depuis la doctrine « Cloud au centre ».
-
Allemagne : référentiel C5 du BSI.
-
Espagne : ENS (Esquema Nacional de Seguridad).
-
Union européenne : projet EUCS toujours en discussion, et initiative GAIA-X pour la fédération de cloud européens.
Point dur du marché : à ce jour, aucune plateforme CASB/SSE majeure n'est qualifiée par ces référentiels les plus exigeants. Pour les organisations soumises à des contraintes de souveraineté fortes, cela impose un arbitrage : accepter un compromis (CASB américain sur données non critiques), s'orienter vers des solutions plus modestes mais conformes, ou construire en interne. Hors UE, des problématiques équivalentes existent (data residency en Asie, lois russes/chinoises sur la localisation).
CASB, DLP, SSE, SASE, Zero Trust : qui fait quoi ?
- La DLP protège la donnée.
- Le CASB protège l'usage du cloud.
- Le SWG protège la navigation web.
- Le ZTNA protège l'accès aux applications privées.
Depuis 2022, Gartner a remplacé le Magic Quadrant CASB par celui du SSE (CASB + SWG + ZTNA), puis a créé en parallèle un Magic Quadrant SASE Platforms (SSE + SD-WAN intégrés en single-vendor). Le SASE est l'implémentation réseau du principe Zero Trust : convergence du WAN sécurisé et de la sécurité cloud-delivered, avec décision d'accès basée sur l'identité et le contexte plutôt que sur le périmètre.
Choix stratégique structurant en 2026 :
-
SASE single-vendor (Cato Networks, Palo Alto Prisma SASE, Zscaler+SD-WAN, Netskope+SD-WAN, Fortinet…) : simplicité opérationnelle, console unique, mais lock-in fort.
-
SSE-only + SD-WAN tiers : meilleur best-of-breed, mais intégration plus complexe.
Il ne faut pas se limiter au seul Gartner pour évaluer ces plateformes. Forrester Wave (SSE Solutions), IDC MarketScape, Frost Radar (où Adaptive Shield a été désigné Leader SSPM 2024) et Gartner Peer Insights apportent des perspectives complémentaires utiles en RFP.
Solutions du marché (mai 2026)
Les offres CASB se répartissent aujourd'hui en trois familles, dont les frontières s'estompent au fil de la convergence « data security platform » :
Plateformes SSE Leaders (CASB intégré à une plateforme cloud-native)
-
Netskope One — Leader Gartner SSE depuis 2022, précurseur sur la sécurité GenAI.
-
Zscaler — Leader Gartner SSE pour la 4ᵉ année consécutive, fort sur l'inline.
CASB intégré à une suite plus large
-
Microsoft Defender for Cloud Apps (ex-MCAS) — désormais brique de Microsoft Purview, qui en a fait la plateforme data security unifiée pour l'écosystème M365.
-
Palo Alto Prisma SaaS Security — dimension CASB/SSPM dans Prisma SASE.
-
Cisco Cloudlock — désormais l'une des briques de Cisco Secure Access, la plateforme SSE de Cisco qui unifie CASB, SWG (Umbrella), DNS Security et ZTNA.
CASB historiques en transition vers le SSE
-
Skyhigh Security (ex-McAfee MVISION Cloud) — Niche Player MQ SSE 2025, historique fort sur le CASB pur, particulièrement sur reverse proxy/BYOD.
-
Forcepoint ONE — plateforme SSE incluant CASB et DLP.
Modèle économique
Modèle commercial par utilisateur et par an, modulé par les briques activées (CASB seul, CASB + SWG, plateforme SSE complète). Les écarts entre éditeurs et entre régions sont importants, et les listes de prix publiques ne reflètent pas la réalité : volume, secteur, contrat-cadre et négociation divisent souvent les tarifs par 2 ou 3 par rapport au « list price ».
À budgéter en plus de la licence : intégration (souvent 20 à 40 % du coût licence en année 1), formation, et ressources de run au SOC. Discipline RSSI recommandée : souscrire d'abord aux modules réellement utilisés, puis élargir.
Cas d'usage : une banque de taille moyenne déploie un CASB pour M365
Contexte : 4 000 collaborateurs, M365 généralisé, télétravail à 50 %, Shadow IT croissant, obligations DORA en application depuis janvier 2025.
Séquence type sur 6 mois :
-
M1-M2 : déploiement en mode discovery sur les logs du proxy. Découverte de 280 apps SaaS dont seulement 35 sanctionnées. Constitution d'un comité catalogue (DSI + RSSI + DPO + métiers).
-
M2-M3 : connexion API à M365 et Salesforce. Cartographie de 6 200 partages publics OneDrive — dont 180 contenant des données client réglementées. Nettoyage piloté avec les métiers.
-
M3-M4 : politiques AI access sur Shadow AI (ChatGPT.com, Gemini grand public) en mode audit, puis bloquant après communication interne. Migration encadrée vers Copilot Enterprise.
-
M4-M5 : UEBA activé sur les comptes admin et les directions sensibles (DRH, fusions-acquisitions). 3 comptes compromis détectés en un mois.
-
M5-M6 : intégration SIEM (Sentinel) avec corrélation EDR/CASB/IdP, playbooks SOAR (révocation session + désactivation compte + alerte SOC sous 2 minutes).
Écueils observés :
- Sous-estimation du temps de conduite du changement : les directions métier ont mal vécu les premiers blocages.
- Friction avec le DPO sur la durée de conservation des logs UEBA (résolue par anonymisation après 6 mois).
-
Coût d'intégration supérieur de 35 % au prévisionnel (PoPs européens insuffisants au démarrage, ajout d'un PoP dédié négocié).
KPIs au bout de 6 mois :
- Apps sanctionnées : 35 → 58 (process catalogue actif).
- Partages publics sensibles : 180 → 4.
- Tokens OAuth dormants révoqués : 1 200.
- Incidents notifiés DORA dans les délais : 100 %.
Ce type de séquence est représentatif des déploiements réussis. Les déploiements qui échouent sautent généralement le M1-M2 (pas de gouvernance) ou le M5-M6 (pas d'intégration SOC).
🚀 Par où commencer ? (récapitulatif)
Cinq étapes opérationnelles :
- Découvrir le Shadow IT (mode discovery) et bâtir le catalogue applicatif officiel.
- Sécuriser les apps sanctionnées critiques (M365, Google Workspace, Salesforce) via API.
- Cartographier et nettoyer les apps OAuth tierces et les tokens dormants.
- Encadrer partages externes et usage GenAI (Shadow AI bloquée, AI sanctionnée gouvernée).
- Activer l'UEBA + intégration SIEM/SOAR, puis passer en inline sur les cas les plus risqués.
À mener en parallèle :
- Conformité réglementaire (DORA, NIS2, RGPD) avec DPO et juridique.
- Prospective NHI / agents IA pour anticiper 2027.
À chaque étape, valider avec métiers et DPO avant blocage.
✅ Conclusion
Le CASB n'est pas un outil « de plus » : c'est la brique qui réconcilie la sécurité avec la réalité du cloud. Sans lui, une part importante des flux de données échappe simplement aux radars de la DSI.
Mais un projet CASB est avant tout un projet de gouvernance déguisé en projet technique. Son succès dépend autant du catalogue applicatif, de la conduite du changement, de la conformité réglementaire et des choix de souveraineté, que de la qualité de la plateforme choisie.
Couplé au ZTNA — qui sécurise l'accès aux applications privées là où le CASB sécurise l'usage des applications SaaS publiques — il couvre l'intégralité du périmètre applicatif moderne. Combiné à la DLP, au SSPM, à l'IAM et à un SIEM/SOAR mature, il s'inscrit dans une architecture de sécurité moderne dont le Zero Trust est le principe directeur : ne plus faire confiance à un périmètre, mais à un contexte (utilisateur, terminal, application, donnée, et bientôt agent IA).
➡️ Dans le prochain article, nous explorerons le ZTNA : pourquoi il remplace progressivement le VPN, et comment il s'articule avec le CASB et la DLP dans une architecture SASE.