L’entreprise moyenne exploite plus de 100 applications SaaS. Le service informatique ne connaît généralement qu’une fraction d’entre elles. Le rapport 2026 SaaS Benchmark Report de Torii a révélé que plus de 61 % des applications découvertes dans l’entreprise moyenne ne sont pas formellement approuvées ou supervisées par le service informatique. Ces applications non approuvées créent des risques de fuite de données et des angles morts en matière de conformité que la plupart des équipes ne découvrent qu’après un problème.
Un courtier en sécurité d’accès au nuage (CASB) est la technologie conçue pour combler cette lacune. Mais les produits CASB autonomes sont en train de disparaître. Gartner a intégré le carré magique CASB dans son évaluation Security Service Edge (SSE) il y a plusieurs années, et les principaux fournisseurs de CASB ont été rachetés ou absorbés dans des plateformes plus larges. Pour la plupart des organisations aujourd’hui, la capacité CASB vit à l’intérieur d’une plateforme SASE. Ce billet explique ce que fait le CASB, comment il fonctionne et pourquoi il n’est plus judicieux de l’acheter séparément.
Qu’est-ce qu’un CASB et que fait-il ?
Un courtier en sécurité d’accès au nuage est une couche de sécurité qui s’interpose entre les utilisateurs et les applications en nuage. Il découvre quels services SaaS sont utilisés, applique les politiques d’accès et de partage des données, détecte les comportements à risque et empêche les données sensibles de quitter l’organisation par des canaux non autorisés. Le CASB offre aux équipes informatiques une visibilité et un contrôle sur l’utilisation du cloud que les paramètres de sécurité SaaS natifs ne peuvent pas fournir seuls.
Le problème résolu par les CASB : l’informatique fantôme et la prolifération des SaaS
L’informatique fantôme n’est pas un risque théorique. C’est la réalité quotidienne de toute équipe informatique gérant une organisation de taille moyenne.
Microsoft a indiqué qu’environ 80 % des employés utilisent des applications non autorisées pour effectuer leur travail. L’enquête 2025 State of SaaS Security de la Cloud Security Alliance a révélé que 55 % des employés adoptent des outils SaaS sans impliquer le moins du monde l’équipe chargée de la sécurité. Et Gartner prévoit que d’ici 2027, trois employés sur quatre acquerront, modifieront ou créeront des technologies en dehors de la supervision des services informatiques.
Les chiffres deviennent plus concrets lorsque vous examinez les environnements réels. Les organisations pensent qu’elles utilisent environ 90 services en nuage. L’utilisation réelle dépasse souvent les 1 000. L’analyse de 23 000 environnements SaaS réalisée par Grip Security en 2025 a révélé que les organisations utilisent en moyenne 140 applications SaaS basées sur l’IA, la plupart d’entre elles ayant été adoptées sans évaluation formelle.
C’est dans cet écart entre l’utilisation perçue et l’utilisation réelle que réside le risque. Un employé s’inscrit à un service de partage de fichiers en utilisant son courriel d’entreprise. Une équipe de marketing commence à utiliser un outil de rédaction par IA qui ingère des notes de synthèse confidentielles. Un analyste financier connecte un compte de stockage cloud personnel pour exporter des rapports. Aucune de ces actions ne nécessite de privilèges d’administrateur. Aucune ne déclenche d’alerte dans les outils de sécurité traditionnels.
Les conséquences sont réelles. L’enquête mid-2025 d’AppOmni a révélé que 75% des organisations ont connu un incident de sécurité SaaS au cours des douze derniers mois, avec une part importante liée directement à des applications non autorisées. Lorsque vous combinez la prolifération des outils avec la montée de l’IA fantôme, la surface d’attaque s’étend plus rapidement qu’aucun processus de gouvernance manuel ne peut le suivre.
Fonctionnement d’un CASB : modes proxy, API et inline
Les produits CASB utilisent trois modes de déploiement pour inspecter et contrôler le trafic dans le nuage. Chacun a un rôle différent et les plateformes modernes les combinent généralement.
| Mode de fonctionnement | Comment fonctionne-t-il ? | Ce qu’il attrape | Limitation |
|---|---|---|---|
| Proxy de transfert | Achemine le trafic utilisateur via le CASB avant qu’il n’atteigne l’application en nuage. | Application des politiques en temps réel, DLP en ligne, contrôle d’accès | Nécessite un agent ou un fichier PAC sur les postes de travail |
| Proxy inverse | Se place devant l’application en nuage, interceptant le trafic du côté de l’application. | Contrôle d’accès sans agent, gestion des sessions | Nécessité d’une configuration spécifique à l’application, risque d’interruption de la fonctionnalité |
| Basé sur l’API | Connexion directe aux plateformes SaaS via leurs API (par exemple Microsoft Graph, Google Workspace API) | Analyse des données au repos, audits des autorisations de partage, DLP rétrospectif | Pas de blocage en temps réel, dépendant de la couverture de l’API |
Dans un contexte SASE, les modes forward proxy et API sont les plus importants. Le forward proxy fait partie du pipeline d’inspection en ligne de la plateforme, où le trafic est décrypté une fois et inspecté simultanément par SWG, CASB, DLP et d’autres moteurs. C’est ce que l’industrie appelle l’inspection en un seul passage. Si vous souhaitez comprendre comment ce pipeline s’articule entre tous les composants de SASE, le guide d’architecture SASE de Jimber présente le flux de données complet.
Le mode API fonctionne en parallèle. Il se connecte aux plateformes SaaS approuvées pour vérifier les autorisations de partage, rechercher des données sensibles dans les fichiers stockés et signaler les dérives de configuration. Les deux modes sont complémentaires et non concurrents. Le mode Inline détecte les menaces en mouvement. API détecte les risques au repos.
CASB vs SWG : ce que chacun protège et où ils se chevauchent
C’est l’une des questions les plus fréquentes que se posent les équipes informatiques lorsqu’elles évaluent la sécurité de l’informatique dématérialisée. La réponse est simple : Le SWG et le CASB inspectent le même flux de trafic, mais examinent des choses différentes.
| Capacités | GTS | CASB |
|---|---|---|
| Objectif principal | Trafic web (tous les HTTP/HTTPS) | Activité des applications en nuage |
| Ce qu’il inspecte | URL, domaines, catégories de contenu, signatures de logiciels malveillants | Actions au niveau de l’application : chargements, téléchargements, partages, appels API |
| Exemples de politiques | Bloquer les sites de jeux d’argent, rechercher les logiciels malveillants dans les téléchargements, faire respecter l’utilisation acceptable. | Bloquez le partage de fichiers vers des comptes personnels, détectez les exportations de données en masse, limitez l’accès des invités. |
| Détection de Shadow IT | Limitée (peut voir quels domaines sont visités) | Forte (identifie des applications spécifiques et des schémas d’utilisation) |
| Portée de la DLP | Filtrage au niveau des URL et des fichiers | Classification des données en fonction de l’application, inspection du contenu en contexte |
| Chevauchement | Les deux inspectent le trafic HTTPS et peuvent bloquer les contenus malveillants. |
La distinction est importante car la SWG protège contre les menaces web, tandis que la CASB protège contre les risques liés aux données en nuage. Une passerelle Web sécurisée empêchera un utilisateur de visiter un site d’hameçonnage connu. Elle n’empêchera pas ce même utilisateur de partager une feuille de calcul confidentielle avec un compte Gmail externe par l’intermédiaire d’une application SaaS approuvée.
Dans une plateforme SASE unifiée, les deux moteurs partagent le même cadre politique et le même pipeline d’inspection du trafic. Il n’est pas nécessaire de choisir entre les deux. Les politiques définies pour l’accès au web et le contrôle des applications en nuage coexistent dans une seule console et s’appliquent de manière cohérente à l’ensemble du trafic. Pour un examen plus approfondi de la façon dont les métriques spécifiques aux GTS sont liées à ce processus, l’article sur les métriques GTS qui comptent vraiment explique ce qu’il faut mesurer et pourquoi.
Pourquoi les CASB autonomes disparaissent-ils ?
Le marché des CASB a connu une consolidation rapide. Comprendre cette trajectoire permet d’expliquer pourquoi il est de plus en plus difficile et contre-productif d’acheter un CASB en tant que produit autonome.
Gartner a cessé de publier un Magic Quadrant CASB autonome et a intégré la catégorie dans son évaluation de l’ESS. Il ne s’agit pas d’une reclassification mineure. Elle reflète la reconnaissance par l’ensemble du marché du fait que le contrôle d’accès au nuage ne peut être séparé de la sécurité web, de l’accès sans confiance et de l’application des politiques au niveau du réseau sans créer de lacunes.
Le paysage des fournisseurs raconte la même histoire. L’activité CASB entreprise de McAfee est devenue Skyhigh Security après la scission consommateur-entreprise. Le CASB de Symantec a été absorbé dans le portefeuille de Broadcom. Bitglass a été racheté par Forcepoint. Tous les grands fournisseurs de CASB autonomes ont été rachetés ou ont pivoté pour offrir une plateforme SSE ou SASE plus large.
Pour un responsable informatique qui évalue les options aujourd’hui, cela a des implications pratiques. Il existe encore des produits CASB autonomes, mais ils entraînent des frais généraux d’intégration. Vous devez les alimenter en trafic (via des chaînes de proxy ou des connexions API), maintenir des consoles de politique distinctes, corréler les journaux entre les outils et gérer une autre relation avec le fournisseur. C’est exactement le problème de la prolifération des outils qui pousse les équipes du marché intermédiaire à se consolider en premier lieu.
La question n’est plus « quel CASB dois-je acheter ? » mais « ma plateforme SASE inclut-elle les capacités CASB dont j’ai besoin ? Il s’agit plutôt de savoir si ma plateforme SASE comprend les capacités CASB dont j’ai besoin.
Comment fonctionne le CASB au sein d’une plateforme SASE
Dans une plateforme SASE intégrée, le CASB est l’un des moteurs d’inspection du pipeline à passage unique. Le trafic en provenance des utilisateurs, des sites et des appareils est acheminé vers le point de présence le plus proche, où il est décrypté une fois et analysé simultanément par les moteurs SWG, CASB, DLP, pare-feu et de prévention des intrusions. Après inspection, le trafic est recrypté et acheminé vers sa destination.
Cette architecture élimine plusieurs problèmes que posent les déploiements de CASB autonomes.
Pas de déploiement séparé. Le CASB s’active par le biais d’un basculement de politique, et non d’une appliance ou d’une chaîne de proxy distincte. Il n’y a pas d’infrastructure supplémentaire à installer, à configurer ou à entretenir.
Modèle de politique cohérent. Le même contexte d’identité et d’état de l’appareil qui régit les décisions d’accès au ZTNA informe également les règles du CASB. Lorsqu’un utilisateur se connecte à partir d’un appareil géré avec un contrôle de posture valide, il obtient un ensemble d’autorisations pour les applications en nuage. À partir d’un appareil non géré, il obtient un ensemble restreint. Un moteur de politique, une logique.
Piste d’audit unique. Tous les événements d’accès au web, les activités des applications en nuage, les détections DLP et les décisions d’accès apparaissent dans un seul flux de journaux. Cela est important pour la conformité NIS2 et GDPR, où les auditeurs s’attendent à voir une image cohérente de qui a accédé à quoi, quand et d’où.
La plateforme SASE de Jimber intègre la visibilité SaaS, le contrôle des applications et la prévention des pertes de données dans la même console qui gère ZTNA, SWG, FWaaS et SD-WAN. La découverte des applications cloud s’effectue automatiquement sur l’ensemble du trafic inspecté. Les règles de politique pour les applications sanctionnées et non sanctionnées sont définies en même temps que le filtrage web et les politiques d’accès. Pour les équipes du marché intermédiaire qui comptent entre trois et dix personnes chargées de gérer tout ce qui va des ordinateurs de bureau aux pare-feux, cette consolidation fait la différence entre une capacité qui est configurée et une autre qui reste inutilisée.
Ce qu’il faut rechercher lors de l’évaluation du CASB dans SASE
Toutes les plateformes SASE n’offrent pas les mêmes capacités CASB. Lors de l’évaluation des options, cinq critères permettent de distinguer une couverture adéquate d’une véritable sécurité des applications en nuage.
Couverture des applications SaaS. La plateforme doit découvrir et classer automatiquement les applications en nuage sur la base de modèles de trafic réels, et pas seulement sur la base d’un catalogue statique. Recherchez une couverture d’au moins plusieurs milliers d’applications, y compris les outils régionaux et sectoriels que vos équipes sont susceptibles d’utiliser.
Prise en charge en ligne et par API. L’inspection en ligne en temps réel permet d’attraper les menaces en mouvement. L’analyse basée sur l’API vérifie les données au repos dans des plateformes approuvées telles que Microsoft 365, Google Workspace et Salesforce. Vous avez besoin des deux. Si un fournisseur ne propose que le mode en ligne, vous perdez toute visibilité sur les autorisations de partage et les risques liés aux données stockées.
Intégration DLP. La prévention des pertes de données devrait partager le même moteur de classification que le CASB, et non fonctionner comme un module séparé avec sa propre console de politique. Lorsqu’une règle DLP détecte des données sensibles dans un téléchargement en nuage, la politique CASB doit appliquer la réponse automatiquement.
Rapports de conformité. Pour les organisations soumises aux exigences de conformité NIS2, GDPR ou DORA, la plateforme doit générer des journaux prêts à être audités qui mettent en correspondance l’activité de l’application cloud avec les contrôles réglementaires. Ceci est particulièrement pertinent pour les organisations européennes qui choisissent des alternatives locales de SASE plutôt que des méga-vendeurs basés aux États-Unis, où la souveraineté des données et la juridiction d’inspection sont importantes.
Gestion multi-locataires. Pour les partenaires de services qui gèrent plusieurs environnements clients, la capacité CASB doit fonctionner dans le cadre de l’architecture multi-locataires de la plateforme. Des politiques distinctes par locataire, une visibilité consolidée entre les locataires et des rapports par locataire ne sont pas négociables pour la fourniture de services gérés.
Questions fréquemment posées
Que signifie CASB ?
CASB est l’acronyme de Cloud Access Security Broker (courtier en sécurité de l’accès au nuage). Il s’agit d’une technologie de sécurité qui s’interpose entre les utilisateurs et les services en nuage afin d’appliquer des politiques de sécurité des données, de conformité et de protection contre les menaces pour les applications SaaS.
Quelle est la différence entre un CASB et un pare-feu ?
Un pare-feu contrôle le trafic en fonction des ports, des protocoles et des adresses IP au niveau du réseau. Un CASB opère au niveau de l’application, en inspectant la manière dont les utilisateurs interagissent avec des services en nuage spécifiques. Il peut détecter des actions telles que le partage de fichiers, les téléchargements en masse et les changements d’autorisation pour lesquels un pare-feu n’a aucune visibilité.
Ai-je besoin d’un CASB distinct si je dispose d’une plateforme SASE ?
Dans la plupart des cas, non. Les plateformes SASE modernes incluent le CASB en tant que moteur d’inspection intégré. L’achat d’un CASB séparé en plus d’une plateforme SASE crée des consoles de politiques en double, des frais généraux d’intégration et une fragmentation des journaux. L’exception est si la capacité CASB de votre fournisseur de SASE est limitée, auquel cas la meilleure solution est généralement de choisir un autre fournisseur de SASE.
Le CASB fonctionne-t-il avec Microsoft 365 ?
Oui. Le CASB se connecte à Microsoft 365 via l’API (à l’aide de Microsoft Graph) et inspecte le trafic en ligne. Le mode API vérifie les autorisations de partage, analyse les fichiers OneDrive et SharePoint à la recherche de données sensibles et détecte les changements de configuration. Le mode Inline applique des politiques en temps réel sur les chargements, les téléchargements et le partage externe.
Le CASB est-il nécessaire pour la conformité NIS2 ?
La norme NIS2 n’impose pas le CASB par son nom. Toutefois, il est difficile de satisfaire aux exigences de la NIS2 en matière de contrôle d’accès, de détection des incidents, de gestion des risques de la chaîne d’approvisionnement et de protection des données sans disposer d’une visibilité sur l’utilisation des applications en nuage. Le CASB fournit la couche SaaS de cette visibilité. Pour les organisations concernées, la capacité CASB au sein d’une plateforme SASE est un moyen pratique de répondre à plusieurs contrôles NIS2 à partir d’une seule plateforme.
Comment le CASB détecte-t-il l’informatique parallèle ?
Le CASB analyse l’ensemble du trafic sortant afin d’identifier les services en nuage utilisés. Il compare le trafic observé à une base de données d’applications connues et les classe en fonction du niveau de risque, des pratiques de traitement des données et des certifications de conformité. Les équipes informatiques disposent ainsi d’une image complète des services réellement utilisés par les employés, par rapport aux applications officiellement approuvées.
La plateforme SASE de Jimber comprend la découverte d’applications cloud, l’application de politiques SaaS et la prévention de la perte de données dans une seule console, aux côtés de ZTNA, SWG, FWaaS et SD-WAN. Si votre équipe cherche à contrôler l’utilisation des SaaS sans ajouter un autre outil autonome, réservez une démonstration et voyez comment cela fonctionne dans un environnement de taille moyenne.
