Qu’est-ce que SASE ? Définition, composants et réalité terrain pour les PME
SASE est l’un des concepts les plus cités dans les discussions sur la sécurité réseau des entreprises, et l’une des architectures qui reviennent souvent lorsqu’une organisation se demande s’il vaut mieux mettre en place un VPN externe ou interne. Les éditeurs l’utilisent pour qualifier leurs plateformes, les analystes pour décrire une évolution structurelle des architectures, les intégrateurs pour justifier des projets de transformation. On se retrouve sur un terme qui circule beaucoup, souvent déconnecté de la seule question qui compte, répond-il réellement aux contraintes de l’entreprise, ou ajoute-t-il surtout de la complexité ?
SASE : Définition et clarifications indispensables
SASE, prononcé « sassi », est l’acronyme de Secure Access Service Edge. Le terme a été formalisé et popularisé par Gartner en 2019, dans le rapport The Future of Network Security Is in the Cloud. Il désigne un cadre architectural qui fusionne les fonctions de connectivité étendue (WAN) et les fonctions de sécurité réseau dans un service distribué, délivré depuis le cloud, au plus près des utilisateurs et des terminaux.
Le point de départ est un constat simple : les architectures réseau héritées supposent que les données, les applications et les utilisateurs se trouvent à l’intérieur d’un périmètre fixe. Cette hypothèse ne tient plus lorsque les applications critiques vivent sur des services cloud, que les équipes travaillent depuis des emplacements variables, et que les accès distants se multiplient. SASE propose une réponse architecturale à ce glissement.
SASE n’est pas un produit autonome ni une technologie unique. Les éditeurs commercialisent des plateformes qui couvrent tout ou partie de ce cadre architectural, certaines sous l’étiquette « SASE unifié », d’autres sous forme de briques séparées. La conformité à l’étiquette ne garantit pas la couverture fonctionnelle réelle. C’est le premier point à garder en tête avant toute discussion commerciale.
Les confusions à écarter
SASE et SSE, ce n’est pas pareil.
En 2021, Gartner a introduit le concept de Security Service Edge (SSE) pour désigner le sous-ensemble cloud-only de SASE : il regroupe les composants de sécurité (SWG, CASB, ZTNA, FWaaS) sans inclure la partie connectivité réseau (SD-WAN). Beaucoup d’offres commerciales couvrent le SSE sans adresser le réseau, ce qui peut suffire selon le contexte, mais ne constitue pas une architecture SASE complète. La distinction compte, surtout au moment de lire une fiche produit.
SASE et Zero Trust ne sont pas interchangeables non plus.
Zero Trust est un principe de sécurité : ne jamais accorder de confiance implicite à un utilisateur, un terminal ou une connexion, même depuis l’intérieur du réseau, vérification continue de l’identité et du contexte à chaque accès. C’est une philosophie d’architecture, définie notamment par le NIST dans sa publication SP 800-207. Pour comprendre ce que Zero Trust change réellement dans une architecture d’accès, il faut d’abord distinguer le principe de sécurité de l’outillage qui l’implémente. SASE est un cadre architectural qui peut intégrer des mécanismes Zero Trust, notamment via sa composante ZTNA. Mais SASE peut exister sans Zero Trust cohérent, et Zero Trust peut être mis en œuvre indépendamment de toute architecture SASE. Les deux concepts se complètent, ils ne se substituent pas l’un à l’autre.
ZTNA et SDP sont proches, sans être interchangeables.
Le ZTNA désigne une fonction d’accès conditionnel aux applications, fondée sur l’identité et le contexte. Le SDP renvoie plutôt à une famille d’architectures qui a influencé certaines implémentations modernes de l’accès distant sécurisé. Dans la pratique, ces approches visent souvent à réduire ou remplacer une partie des usages du VPN d’accès distant, en déplaçant le contrôle du niveau réseau vers le niveau applicatif. Cette logique d’accès applicatif plutôt que réseau éclaire bien la différence entre un SDP et un VPN traditionnel.
Les composants de SASE : ce qu’ils résolvent, ce qu’ils ajoutent
SASE converge cinq grandes catégories de fonctions. Pour chacune, la question utile n’est pas seulement « qu’est-ce que c’est ? », c’est « quel problème ça traite, et quelle dépendance ça crée ? » Le choix des protocoles VPN pour une entreprise est d’ailleurs directement lié à la manière dont certains de ces composants s’articulent avec l’infrastructure existante.
| Composant | Sigle | Ce que ça résout | Ce que ça ajoute comme dépendance |
|---|---|---|---|
| Réseau étendu défini par logiciel | SD-WAN | Connectivité multi-site intelligente, optimisation du routage applicatif, réduction des coûts de liaison dédiée | Gestion centralisée des politiques réseau, compétences spécifiques |
| Pare-feu en tant que service | FWaaS | Filtrage du trafic réseau depuis le cloud, sans appliance physique sur site | Dépendance à la disponibilité et aux SLA du fournisseur cloud |
| Passerelle web sécurisée | SWG | Inspection approfondie du trafic web sortant (URL, contenu, menaces) | Peut impliquer une inspection TLS, avec enjeux de gestion des certificats, de compatibilité applicative et de confidentialité interne |
| Courtier de sécurité d'accès au cloud | CASB | Visibilité et contrôle sur l'usage des applications SaaS, détection des usages non autorisés | Nécessite un inventaire suffisamment fiable des usages cloud pour définir des règles utiles |
| Accès réseau à confiance zéro | ZTNA | Contrôle d'accès granulaire aux applications, basé sur l'identité et le contexte | Suppose un annuaire propre, des identités gérées et des politiques d'accès définies par application |
Ces composants ne forment une architecture cohérente que si les couches sous-jacentes sont en place. Le CASB, en particulier, suppose une maîtrise préalable des usages, ce qui renvoie directement aux bonnes pratiques SaaS en entreprise. C’est précisément ce que les présentations commerciales omettent le plus souvent.
Les prérequis trop souvent laissés au second plan
C’est le point le plus honnête à formuler sur SASE : le cadre architectural suppose des fondations qui, dans beaucoup d’organisations, n’existent pas encore.
Déployer des composants SASE sur une infrastructure dont la gestion des identités est fragmentée, les politiques d’accès mal définies ou les terminaux non maîtrisés ne produit pas de la modernité. Ça déplace la complexité vers un niveau d’abstraction plus élevé, en ajoutant des dépendances sans avoir résolu les problèmes structurels.
Ce qu’il faut avoir en place avant d’envisager une migration sérieuse :
- Un annuaire propre et consolidé. Les identités des utilisateurs, des terminaux et des applications doivent être gérées de manière centralisée et cohérente, Microsoft Entra ID, Okta ou équivalent.
- Une authentification forte généralisée. SSO et MFA déployés sur l’ensemble des accès critiques, pas uniquement sur quelques applications pilotes.
- Une gestion minimale des terminaux. Savoir quels appareils accèdent au réseau, dans quel état de configuration, est un prérequis au contrôle contextuel que SASE est censé apporter.
- Des politiques d’accès définies par application. Le ZTNA n’a de sens que si on sait précisément qui doit accéder à quoi. Sans cette cartographie préalable, on reconfigure un accès réseau en accès applicatif sans améliorer le contrôle réel.
- Une cartographie minimale des flux et dépendances applicatives. Sans visibilité sur les applications réellement utilisées, les chemins d’accès et les exceptions métier, la promesse de simplification tourne vite au déplacement de complexité.
- Une capacité d’exploitation dans la durée. Une architecture distribuée dans le cloud délègue la sécurité à des tiers. Elle suppose une équipe, interne ou prestataire, capable de surveiller les alertes, d’interpréter les journaux et de gérer les incidents dans ce nouveau modèle.
Quand SASE est pertinent : et quand regarder ailleurs
Il n’existe pas de seuil universel. La pertinence d’une architecture SASE dépend de critères de complexité opérationnelle, pas d’une taille d’effectif.
- Plusieurs sites géographiques avec des besoins de connectivité hétérogènes
- Forte mobilité des utilisateurs, accès distants nombreux et variés
- Usage intensif de services SaaS et d’applications cloud critiques
- Surface d’exposition large : prestataires externes, partenaires, sous-traitants accédant aux ressources internes
- Équipe IT structurée, ou prestataire capable d’opérer l’architecture dans la durée
Les signaux qui suggèrent de s’arrêter avant :
- Organisation mono-site avec peu d’applications exposées
- Gestion des identités encore fragmentée ou absente
- Pas de politique d’accès formalisée par application
- Aucune visibilité sur les flux applicatifs réels
- Aucune ressource pour opérer et maintenir une architecture distribuée
- Budget et cycle de décision incompatibles avec un projet de transformation pluriannuel
Dans beaucoup de PME, le besoin réel ne porte pas sur une architecture SASE complète, mais sur une partie de ses fonctions : accès applicatif plus fin, meilleure maîtrise des usages SaaS, ou filtrage web cohérent pour les utilisateurs distants. C’est précisément là qu’une approche progressive a plus de sens qu’un projet global de convergence.
Une PME n’a pas besoin de « faire du SASE » pour sécuriser sérieusement ses accès. Elle a besoin de résoudre ses vrais problèmes dans le bon ordre : identité, accès distant, visibilité sur les usages cloud, segmentation des droits, exploitation. Si ces fondations ne sont pas tenues, l’étiquette SASE n’apporte pas de maturité, elle apporte surtout une couche supplémentaire de dépendance et d’intégration.
Pour beaucoup de PME, la trajectoire la plus réaliste passe d’abord par une mise en place cohérente du VPN d’entreprise Zéro Trust, avant toute ambition de convergence plus large.
Questions fréquentes sur SASE
Qui a formalisé le concept de SASE ?
Quelle est la différence entre SASE et SSE ?
Le SSE (Security Service Edge) est un sous-ensemble de SASE défini par Gartner en 2021. Il regroupe les composants de sécurité cloud (SWG, CASB, ZTNA, FWaaS) sans inclure le SD-WAN. Une organisation qui n’a pas besoin de refondre sa connectivité réseau peut opter pour une approche SSE sans engager un projet SASE complet.
SASE remplace-t-il le VPN d'entreprise ?
Partiellement, et progressivement. Le composant ZTNA de SASE vise à remplacer une partie des usages du VPN d’accès distant, en déplaçant le contrôle du niveau réseau vers le niveau applicatif. Dans la pratique, VPN d’entreprise et ZTNA coexistent souvent pendant une période de transition qui peut être longue selon la complexité de l’infrastructure existante.
Faut-il un seul fournisseur pour déployer SASE ?
Non.
SASE est un cadre architectural, pas une offre packagée. Beaucoup d’organisations assemblent plusieurs solutions de fournisseurs différents pour couvrir les composants dont elles ont besoin. Les plateformes « SASE unifié » d’un seul éditeur existent, mais impliquent des effets de verrouillage significatifs à évaluer sérieusement avant engagement.
SASE est-il adapté à une PME ?
Rarement dans sa forme complète. Une architecture SASE intégrale suppose des fondations, annuaire propre, authentification forte généralisée, gestion des terminaux, politiques d’accès définies, cartographie des flux, que beaucoup de PME n’ont pas encore en place. Construire ces fondations en priorité est généralement plus utile qu’adopter l’étiquette.
Quelle est la relation entre SASE et Zero Trust ?
Zero Trust est un principe de sécurité (vérification continue, aucune confiance implicite), défini notamment par le NIST dans sa publication SP 800-207. SASE est un cadre architectural qui peut intégrer des mécanismes Zero Trust, notamment via le ZTNA. L’un est une philosophie, l’autre est une architecture, ils sont complémentaires mais distincts.