Les applications et les équipes se répartissent désormais entre sièges, filiales, domicile, SaaS et clouds publics. Face à cet éclatement, l’architecture SASE rapproche la connectivité étendue des contrôles de protection distribués au plus près des usages.
Ce modèle dépasse le produit unique comme le tunnel VPN traditionnel. Il renouvelle la sécurité réseau dans le cloud en soumettant chaque accès aux ressources à l’identité, l’état du terminal et la destination visée. Elle se heurte à la latence, la dépendance et la confidentialité.
Le SASE réunit connectivité étendue et sécurité distribuée
Formalisé par Gartner en 2019, le SASE, ou Secure Access Service Edge, décrit un modèle architectural, et non un produit monolithique. Il réalise une convergence réseau-sécurité en associant les fonctions WAN à des services cloud distribués, capables d’appliquer les protections au plus près des connexions. Agences, télétravailleurs, appareils, centres de données et environnements multicloud rejoignent ainsi les ressources requises sans repasser systématiquement par le siège.
Les connexions empruntent des points de présence proches, où l’architecture orchestre routage, inspection et application des politiques. Ce contrôle des flux suit des règles cohérentes, que la personne travaille dans une agence, chez elle ou en déplacement. La norme MEF 117, publiée en 2022, encadre les attributs convenus entre fournisseur et client pour bâtir un réseau étendu sécurisé. Ses capacités se répartissent ainsi au sein d’une politique unifiée et lisible.
- Le choix dynamique des chemins réseau grâce au SD-WAN.
- La protection des accès au Web et aux services cloud.
- L’application de règles adaptées aux utilisateurs et aux ressources.
- La centralisation des politiques et des événements de sécurité.
À quels besoins répond cette architecture cloud ?
Le modèle historique « hub-and-spoke » ramène les échanges des agences et des utilisateurs distants vers un centre de données avant Internet. Ce détour fonctionnait lorsque applications et protections demeuraient au siège. Le travail hybride bouleverse cet équilibre : équipes et terminaux accèdent désormais à des ressources dispersées entre clouds publics, infrastructures privées et environnements multicloud. Le passage obligé par le site central devient alors rapidement contre-productif.
Cette centralisation allonge les trajets réseau alors que la destination se situe dans le cloud. Renvoyer une requête destinée aux applications SaaS vers un pare-feu central augmente la latence, encombre le WAN et multiplie les équipements à administrer. Le SASE rapproche l’inspection des utilisateurs et des ressources via des points de présence cloud, sans sacrifier la cohérence des règles. En juin 2024, la CISA et des agences partenaires ont recommandé d’évaluer SASE, SSE et Zero Trust pour réduire les risques distants et améliorer la visibilité réseau.
SD-WAN et SSE forment le socle fonctionnel
Le SASE articule deux familles techniques qui travaillent de concert. Les fonctions du SD-WAN pilotent les liaisons selon la disponibilité, la qualité mesurée et la nature des applications. Il oriente ainsi les flux des agences vers leur destination adaptée, sans transit forcé par le siège. Le SSE apporte, depuis une infrastructure distribuée, les services de sécurité cloud chargés de contrôler ces communications.
Face aux accès web, la passerelle web sécurisée filtre les URL, analyse les contenus et bloque les menaces. Le CASB encadre les services SaaS et repère les usages non autorisés, tandis que le FWaaS applique les règles de pare-feu. Le ZTNA, lui, ouvre seulement l’application privée autorisée après vérification de l’identité et de l’état du terminal. Associées au SD-WAN, ces briques constituent le socle SASE.
| Composant | Fonction assurée | Ressources concernées |
|---|---|---|
| SD-WAN | Pilote les liaisons et oriente les flux | Agences, centres de données et clouds |
| SWG | Filtre les accès web et analyse les contenus | Sites, URL et téléchargements |
| CASB | Encadre les usages des services cloud | Applications SaaS |
| FWaaS | Applique les règles de pare-feu depuis le cloud | Connexions réseau entrantes et sortantes |
| ZTNA | Accorde un accès limité après vérification | Applications privées autorisées |
Comment les flux traversent-ils une plateforme SASE ?
Depuis un terminal distant, un agent SASE prend en charge la session ; dans une agence, cette tâche revient généralement à l’équipement SD-WAN. Tous deux établissent des tunnels réseau sécurisés vers l’un des points de présence, ou PoP, de la plateforme. Le PoP est choisi selon la proximité, la latence et l’état des liaisons, afin d’éviter les détours inutiles. Cet acheminement du trafic rapproche le contrôle de l’utilisateur tout en préservant une route efficace vers la ressource demandée.
À l’arrivée au PoP, le service identifie la requête, l’utilisateur, le terminal et la destination. L’application des politiques détermine alors si la session doit être autorisée, bloquée, inspectée ou limitée. Un flux validé ressort vers Internet, un service SaaS ou une ressource hébergée dans un cloud public. Pour une application privée, la plateforme rejoint un connecteur près de celle-ci, sans exposer la ressource sur Internet ni donner accès à l’ensemble du réseau interne.
L’identité et le contexte orientent chaque décision d’accès
Une demande ne reçoit aucun droit sur la seule preuve d’identité ou parce qu’elle provient du réseau interne. Le moteur de politiques croise l’utilisateur authentifié par l’IdP, son groupe, sa localisation, l’application visée et le niveau de risque calculé. Ce contrôle d’accès contextuel traduit ces signaux en réponse graduée : autorisation complète, restrictions fonctionnelles, authentification renforcée ou refus, selon les règles déjà définies de l’organisation.
Le poste apporte une seconde série d’indices, réévaluée avant la connexion puis durant la session. La posture du terminal renseigne notamment le chiffrement du disque, la version du système, l’état de l’EDR et la conformité aux règles UEM. Ainsi, un salarié reconnu utilisant un appareil non conforme depuis une zone inhabituelle peut obtenir un accès réduit ou subir un contrôle supplémentaire. La fiabilité de la décision dépend de données fraîches, transmises par l’IdP, l’UEM et les outils de sécurité.
À retenir : une identité valide ne suffit pas toujours. L’état de l’appareil et le niveau de risque peuvent modifier les droits accordés pendant la session.
Quelles différences entre SASE, SSE, Zero Trust, ZTNA et VPN ?
Les acronymes voisins ne désignent ni le même périmètre ni le même type de solution. Le SASE associe le SD-WAN aux services de sécurité distribués, alors que le périmètre du SSE réunit SWG, CASB, FWaaS et ZTNA sans prendre en charge la connectivité étendue. Le modèle Zero Trust relève, lui, d’une doctrine : la localisation réseau n’accorde aucune confiance implicite, chaque demande étant jugée selon l’identité, l’appareil et la ressource visée.
Le ZTNA concrétise cette doctrine pour les applications privées en exposant une ressource précise, plutôt qu’un sous-réseau entier. Un VPN crée pour sa part un tunnel chiffré vers l’infrastructure et fournit, selon sa configuration, un accès au réseau privé plus large. Leur coexistence demeure pertinente : les applications compatibles migrent vers le ZTNA, tandis que des protocoles anciens, des administrateurs ou des équipements industriels conservent le VPN. Le choix dépend des usages et contraintes techniques.
| Notion | Nature | Périmètre et usage |
|---|---|---|
| SASE | Architecture de services | Réunit SD-WAN et SSE pour associer connectivité étendue, sécurité des flux et politiques d’accès distribuées. |
| SSE | Ensemble de services de sécurité | Protège les accès au Web, aux services SaaS et aux applications privées, sans composante SD-WAN. |
| Zero Trust | Modèle de sécurité | Évalue chaque demande selon l’identité, l’appareil, la ressource et le risque, sans confiance implicite liée au réseau. |
| ZTNA | Fonction d’accès | Accorde un accès ciblé à une application privée, sans ouvrir nécessairement le réseau qui l’héberge. |
| VPN | Technologie de tunnel chiffré | Relie un terminal ou un site à un réseau distant et reste adapté à certains protocoles ou systèmes hérités. |
La défense en profondeur reste indispensable
Le SASE orchestre les contrôles d’accès et l’inspection des flux, sans former à lui seul une défense complète. Il complète l’IAM, l’authentification multifacteur et l’EDR, dont les signaux alimentent ses décisions. Une identité compromise ou une télémétrie de poste erronée peut fausser l’autorisation. Plusieurs couches demeurent donc autonomes :
- la sécurité des applications, des API et de la messagerie ;
- les sauvegardes isolées et les procédures de restauration ;
- la détection et la réponse sur les postes ;
- la sécurisation du fournisseur d’identité.
Les sauvegardes soutiennent la reprise après incident, tandis que la sécurité applicative traite les failles du code et des API. La protection des terminaux, la segmentation du réseau et la gestion des vulnérabilités réduisent la portée d’une intrusion. Des tests de défaillance vérifient les dépendances entre ces dispositifs, même lorsque le service cloud centralise l’accès et l’analyse du trafic à distance.
Quel modèle de déploiement convient à l’organisation ?
Trois modèles structurent un déploiement SASE. Un fournisseur SASE unique réunit console, moteur de politiques et télémétrie, ce qui réduit les raccordements. Une architecture à deux fournisseurs associe généralement un SD-WAN existant à une plateforme SSE spécialisée ; elle préserve certains investissements, mais accroît les travaux d’intégration. Le modèle managé délègue l’exploitation à un opérateur ou prestataire.
- modèle intégré : administration unifiée et complexité réduite ;
- modèle bifournisseur : technologies spécialisées et interopérabilité accrue ;
- modèle managé : opérations déléguées et responsabilités contractuelles encadrées.
Le choix dépend des compétences internes, des contrats, de la disponibilité attendue et de la dépendance acceptable. Comparez les agents, API, journaux, mécanismes de bascule et responsabilités contractuelles. Une offre dite intégrée peut rester un assemblage de produits. Gartner anticipait en février 2025 une croissance annuelle de 26 % sur cinq ans, portant le marché à 28,5 milliards de dollars en 2028 ; en mai 2026, le cabinet confirmait l’élan lié au travail hybride, au multicloud et à l’intelligence artificielle.
Les gains attendus dépendent de l’infrastructure réelle
Les bénéfices d’une plateforme SASE se vérifient dans les chemins réellement empruntés par les flux, plutôt que dans les seules promesses commerciales. Une politique uniforme réduit les écarts entre agences, télétravailleurs et applications, tandis que la proximité des PoP évite certains détours vers le datacenter central. Encore faut-il que le peering et la performance du backbone procurent un trajet plus court, stable et disponible. Les mesures intègrent latence, débit et pertes de paquets avec toutes les fonctions d’inspection actives.
La consolidation peut remplacer plusieurs passerelles web, pare-feu cloud, accès privés et équipements WAN, sans garantir mécaniquement des économies. Le coût total de possession réunit licences, trafic, options avancées, migration, liaisons réseau, exploitation et services managés. L’évaluation doit comparer la localisation des points de présence, leur capacité sous charge et leur redondance, puis tester les bascules face aux pannes de liens ou de PoP.
Comment encadrer les journaux, les données et l’inspection TLS ?
Les traces produites par le SASE révèlent les identités, destinations, connexions, règles appliquées et alertes utiles aux enquêtes. Une politique de conservation des journaux fixe leur durée, leur localisation, leur chiffrement, leur intégrité et les habilitations d’accès. L’export vers le SIEM doit soutenir la corrélation et l’investigation sans multiplier les copies ni collecter davantage d’informations personnelles que la finalité déclarée ne l’exige. En France, cette discipline suit les recommandations de la CNIL sur la limitation des finalités, volumes et accès.
Déchiffrer HTTPS améliore la détection, mais expose temporairement des contenus auparavant protégés de bout en bout. Toute inspection du trafic chiffré impose des exclusions documentées pour les services sensibles, ainsi qu’une protection des certificats, des clés et des autorités internes. Les catégories inspectées, administrateurs habilités et accès du fournisseur doivent rester traçables. Ce cadre assure la conformité des traitements de données au RGPD sans sacrifier la confidentialité attendue.
Une migration progressive sécurise la mise en service
La migration vers le SASE progresse par étapes mesurables, sans remplacement brutal des services en production. Le recensement couvre utilisateurs, sites, applications, identités, équipements et politiques, tandis que l’inventaire des flux cartographie leurs dépendances. Un pilote limité aux télétravailleurs, à un accès SaaS ou à quelques applications privées révèle les incompatibilités. Il permet d’ajuster les règles trop permissives ou restrictives et de corriger les erreurs avant qu’elles n’affectent l’ensemble de la production.
Durant l’expérimentation, les équipes contrôlent les autorisations et refus, la posture des terminaux, la détection des menaces et la DLP. Elles mesurent le débit, la latence et la perte de paquets. Les tests de bascule simulent l’indisponibilité des liens, des points de présence, de l’IdP, du plan de contrôle ou de l’agent. Le mode hors connexion, l’export des journaux vers le SIEM et leur exhaustivité sont examinés. Les seuils d’acceptation documentés autorisent le déploiement par vagues.