L’architecture de SASE expliquée : composants, flux de données et modèles de déploiement

Qu’est-ce que l’architecture SASE ?

SASE (Secure Access Service Edge) est une architecture en nuage qui fait converger le réseau et la sécurité en une seule plateforme. Au lieu d’acheminer le trafic vers un centre de données central pour l’inspecter, SASE déplace l’application des politiques vers des nœuds distribués dans le nuage, proches des utilisateurs et des applications. Résultat : des connexions plus rapides, une sécurité cohérente quel que soit l’endroit, et une console au lieu d’une douzaine. Gartner a défini le cadre en 2019. D’ici 2026, il sera devenu l’architecture par défaut des organisations qui ont besoin d’une connectivité sécurisée entre les bureaux, les travailleurs à distance, les applications cloud et les appareils connectés.

L’architecture SASE combine cinq fonctions centrales de sécurité et de mise en réseau, applique des politiques à des points de présence distribués et sépare le plan de contrôle du plan de données afin que les règles soient définies une seule fois mais appliquées partout. Pour les entreprises de taille moyenne qui gèrent de 50 à 400 utilisateurs sur plusieurs sites, elle remplace la complexité de la gestion de pare-feu, de concentrateurs VPN, de passerelles web et d’appliances SD-WAN distincts par un service unifié et géré dans le nuage.

Ce guide explique le fonctionnement de l’architecture de A à Z. Vous apprendrez ce que fait chaque composant, comment les données circulent dans le système. Vous apprendrez ce que fait chaque composant, comment les données circulent dans le système, quels sont les modèles de déploiement existants, quelle est la place des points de présence, en quoi SASE diffère de SSE, et ce que les organisations européennes doivent prendre en compte en matière de souveraineté des données et de conformité à NIS2.

Les principaux éléments de l’architecture SASE

Le SASE combine des fonctions de réseau et de sécurité qui étaient traditionnellement fournies par des appareils et des fournisseurs distincts. La définition initiale de Gartner pour 2019 identifiait cinq composants de base. Le paysage 2025-2026 a élargi cet ensemble, mais ces cinq composants restent la base.

SD-WAN : la couche réseau

Le réseau étendu défini par logiciel gère la connectivité entre les succursales, les centres de données, les environnements en nuage et les sites distants. Le SD-WAN intègre l’intelligence du routage dans un logiciel, remplaçant les configurations MPLS statiques par une sélection dynamique des chemins d’accès à large bande, MPLS, 4G/5G ou toute autre combinaison. Un contrôleur central transmet des politiques à des dispositifs légers situés à la périphérie de chaque site. Ces appareils construisent des tunnels superposés cryptés, mesurent la qualité des liaisons en temps réel et acheminent le trafic en fonction de la priorité de l’application et des conditions du réseau. La différence concrète pour les équipes informatiques : des déploiements de sites plus rapides, des coûts de transport moins élevés et un seul endroit pour gérer la connectivité sur tous les sites. Pour en savoir plus sur le fonctionnement du SD-WAN, consultez le guide complet du SD-WAN pour 2026.

ZTNA : accès basé sur l’identité

Zero Trust Network Access remplace les tunnels VPN par un accès granulaire par application. Les utilisateurs s’authentifient, l’état de leur appareil est vérifié et ils n’ont accès qu’aux applications spécifiques requises par leur rôle. Un membre de l’équipe financière accède au système de facturation. Un clinicien accède au dossier médical électronique. Ni l’un ni l’autre ne peut voir les applications de l’autre, et ni l’un ni l’autre ne rejoint un vaste segment de réseau. C’est la principale différence avec le VPN : ZTNA n’accorde jamais d’accès au niveau du réseau, mais uniquement au niveau de l’application. Les mouvements latéraux deviennent structurellement impossibles. Dans la plateforme Jimber, ZTNA est la méthode d’accès par défaut. La confiance zéro est intégrée, elle n’est pas un module optionnel.

SWG : sécurité du web à la périphérie

La passerelle Web sécurisée inspecte et filtre l’ensemble du trafic Web. Elle applique des politiques d’utilisation acceptable par le biais de la catégorisation des URL, bloque les domaines malveillants connus et effectue une inspection TLS lorsque la politique le permet. Dans une architecture SASE, les politiques de la SWG suivent les utilisateurs indépendamment de leur localisation. Un employé naviguant depuis une chambre d’hôtel à Barcelone bénéficie de la même protection qu’un employé travaillant au bureau à Bruxelles. Pour les organisations qui vont au-delà des simples listes de blocage, les mesures SWG qui indiquent réellement la posture de sécurité sont plus importantes que les taux de blocage.

FWaaS : pare-feu en nuage

Le service Firewall-as-a-Service permet de déplacer les fonctionnalités de pare-feu des appareils sur site vers le nuage. Il permet l’inspection approfondie des paquets, la prévention des intrusions, le contrôle des applications et le filtrage des ports/protocoles, le tout sous la forme d’un service géré. Grâce à FWaaS, il n’est plus nécessaire de déployer, de patcher et de gérer du matériel de pare-feu physique sur chaque site. Les politiques sont définies de manière centralisée et appliquées au point de présence le plus proche. Pour les entreprises de taille moyenne disposant de plusieurs sites, cela suffit à réduire le temps de déploiement de plusieurs semaines et les coûts matériels importants de chaque nouveau site.

CASB : contrôle des applications en nuage

Le Cloud Access Security Broker détecte et contrôle l’utilisation des applications SaaS. Il fonctionne selon deux modes. Le mode Inline inspecte le trafic en temps réel lorsque les utilisateurs accèdent aux services cloud, en appliquant les politiques DLP, en bloquant les partages de fichiers non autorisés et en détectant les comportements anormaux. Le mode API se connecte directement aux plateformes SaaS telles que Microsoft 365 ou Salesforce pour analyser les données au repos, vérifier les autorisations de partage et appliquer les règles de conformité. Le CASB est le composant qui rend l’informatique fantôme visible. Sans lui, les équipes informatiques n’ont aucun moyen fiable de savoir quels services cloud les employés utilisent réellement.

Composants élargis en 2025-2026

Les plateformes SASE modernes se sont développées au-delà des cinq premières. Parmi les ajouts courants figure l’isolation du navigateur à distance (RBI), qui exécute le code du site web dans un conteneur en nuage de sorte qu’aucun contenu actif n’atteigne le point de terminaison. La prévention de la perte de données (DLP) recherche des modèles de données sensibles dans l’ensemble du trafic. La surveillance de l’expérience numérique (DEM) mesure les performances de bout en bout, de l’appareil de l’utilisateur à l’application. La sécurité DNS filtre les domaines malveillants avant que les connexions ne soient établies. Certains fournisseurs intègrent également des capacités de détection des points d’extrémité, bien que cela varie considérablement d’une plateforme à l’autre.

Comment les données circulent-elles dans une architecture SASE ?

C’est la partie que la plupart des vendeurs omettent de mentionner. Comprendre ce qui arrive réellement à un paquet lorsqu’il se déplace dans le système fait la différence entre l’évaluation des revendications marketing et l’évaluation de l’architecture.

SASE sépare le plan de contrôle du plan de données. C’est dans le plan de contrôle que se trouvent les politiques. Un contrôleur centralisé, hébergé dans le nuage, détient l’image complète de la topologie de votre réseau, des identités des utilisateurs, des règles de posture des appareils et des politiques de sécurité. Lorsque vous définissez une règle qui stipule que « l’équipe financière ne peut accéder au système ERP qu’à partir d’appareils gérés dont le chiffrement du disque est activé », cette instruction se trouve dans le plan de contrôle et est transmise à chaque point d’application. Le plan de données est l’endroit où les paquets se déplacent réellement. Les points de présence distribués se chargent de recevoir le trafic, de l’inspecter et de l’acheminer vers sa destination.

Étape 1 : établissement de la connexion

L’appareil de l’utilisateur, qui exécute un agent SASE léger, se connecte au point de présence le plus proche via un tunnel crypté. Pour les succursales, une appliance SD-WAN établit ce tunnel. Pour les appareils sans agent tels que les imprimantes, les capteurs ou les équipements industriels, une appliance d’isolation en ligne dédiée, telle que le NIAC de Jimber, achemine le trafic en leur nom.

Étape 2 : vérification de l’identité et du dispositif

Le point de contact vérifie l’identité de l’utilisateur par le biais de l’intégration SSO/IdP à l’aide des protocoles SAML ou OIDC. L’état de l’appareil est vérifié simultanément : le système d’exploitation est-il à jour ? Le chiffrement du disque est-il actif ? La protection des points d’extrémité est-elle en cours d’exécution ? L’appareil est-il géré ou enregistré ? Le contexte est recueilli : emplacement, heure de la journée, type de réseau. Tous ces signaux sont pris en compte dans la décision d’accès.

Étape 3 : Évaluation de la politique de confiance zéro

Le moteur ZTNA évalue si cette identité spécifique, sur ce dispositif spécifique, dans ce contexte spécifique, a la permission d’accéder à la ressource demandée. L’accès est accordé par application en utilisant les principes du moindre privilège. L’utilisateur ne rejoint jamais un segment de réseau. Il n’accède qu’à l’application que la politique autorise.

Étape 4 : inspection de sécurité à passage unique

C’est sur ce point que l’architecture SASE diffère le plus des approches traditionnelles. Le trafic est décrypté une fois, puis inspecté simultanément par tous les moteurs de sécurité : NGFW/FWaaS pour les règles de port, de protocole et d’application. SWG pour la catégorisation des URL et les menaces web. IPS pour les signatures d’attaques connues. Anti-malware pour l’analyse des fichiers. DLP pour les modèles de données sensibles. CASB pour les politiques relatives aux applications en nuage. Sécurité DNS pour la réputation des domaines. Après l’inspection, le trafic est recrypté une fois.

Les anciennes architectures enchaînaient ces fonctions, décryptant et recryptant le trafic à chaque étape. Cinq outils en séquence signifiaient cinq cycles de décryptage-inspection-cryptage, chacun ajoutant de la latence. L’inspection en une seule passe élimine totalement cette surcharge.

Étape 5 : optimisation de l’acheminement

Le trafic inspecté est acheminé vers sa destination par le chemin le plus efficace. Le trafic des applications SaaS sort par le PoP le plus proche de la région du fournisseur, évitant ainsi le backhaul qui ralentit les architectures VPN traditionnelles. Le trafic des centres de données passe par le réseau fédérateur du fournisseur. Le trafic Internet sort directement du point de contact.

Étape 6 : enregistrement et analyse

Chaque session génère une entrée de journal : identité de l’utilisateur, résultat de la posture de l’appareil, application accédée, verdict de sécurité, données transférées, durée de la session. Tout cela alimente un lac de données unifié. Pour les organisations opérant sous NIS2, cette journalisation centralisée n’est pas optionnelle. C’est la piste d’audit qui prouve la proportionnalité des contrôles d’accès et la capacité à contenir les incidents.

Comment le flux de données varie en fonction du type de trafic

Tout le trafic ne suit pas le même chemin. L’architecture gère trois scénarios fondamentalement différents.

Utilisateur à distance de l’application SaaS. Un employé à Bruxelles ouvre un CRM hébergé à Francfort. Son agent SASE se connecte au PoP le plus proche. L’identité et la position de l’appareil sont vérifiées. SWG, CASB et DLP inspectent le trafic en un seul passage. Le trafic sort par le PoP le plus proche du fournisseur SaaS. Temps de latence total : environ 12 ms. La même connexion via une architecture VPN traditionnelle, acheminée par un centre de données central, ajouterait 80 à 120 ms.

De l’agence au centre de données. Une appliance SD-WAN installée sur le site d’une succursale achemine le trafic via un tunnel crypté jusqu’au PoP le plus proche. La plateforme SASE applique une classification QoS adaptée aux applications, donnant la priorité au trafic en temps réel, comme la voix et la vidéo, par rapport aux tâches d’arrière-plan. L’inspection de sécurité complète a lieu au point de contact. Le trafic passe ensuite par la dorsale du fournisseur jusqu’au PoP le plus proche du centre de données, puis sort vers la destination.

Un dispositif sans agent vers le nuage. Une imprimante connectée, un capteur IoT ou un automate industriel ne peut pas exécuter un agent SASE. Il se connecte au réseau local, où une appliance d’isolation réseau dédiée achemine son trafic. Jimber utilise du matériel NIAC à cette fin, plaçant chaque appareil derrière une couche d’isolation en ligne qui contrôle exactement les systèmes en amont qu’il peut atteindre. L’appareil est identifié par une empreinte digitale pilotée par l’intelligence artificielle et basée sur l’adresse MAC, les schémas de trafic et les signatures DPI. La politique de microsegmentation limite la communication de l’appareil aux seuls systèmes en amont désignés. Le baselining comportemental surveille les anomalies. Si l’appareil commence à tenter des connexions en dehors des flux autorisés, l’accès est immédiatement restreint.

Ce troisième scénario est celui que la plupart des fournisseurs ignorent. Pourtant, pour les entreprises qui exploitent des équipements de fabrication, des systèmes de gestion des bâtiments, des appareils médicaux ou tout autre environnement doté d’un matériel sans agent, il s’agit du flux de données le plus important à comprendre. C’est également sur ce point que l’architecture Jimber se distingue le plus de ses concurrents : NIAC est un composant conçu à cet effet, et non un élément ajouté après coup à une conception axée sur l’agent.

Le rôle des points de présence dans les SASE

Les points de présence sont les nœuds distribués dans le nuage où s’exécute la pile SASE. Chaque point de présence contient généralement plusieurs nœuds de calcul pour la redondance, la pile complète d’inspection de sécurité, l’intelligence de routage SD-WAN, des connexions aux FAI de niveau 1 et aux points d’échange Internet, ainsi que des accords d’échange de trafic avec les principaux fournisseurs de services en nuage.

Le nombre de PoP est l’indicateur le plus mis en avant par les fournisseurs. Les grands fournisseurs américains revendiquent entre 85 et plus de 330 PoP dans le monde. Mais le nombre brut de PoP est trompeur. Les recherches menées par les principaux fournisseurs de SASE eux-mêmes montrent que la proximité des PoP représente environ 5 % de la latence de bout en bout. La latence du côté de l’application et l’acheminement sur le kilomètre intermédiaire y contribuent bien davantage. Des études indépendantes ont également montré que le nombre de PoP annoncé par certains fournisseurs ne reflète pas le nombre de PoP réellement utilisables par client. Ce qui compte, ce n’est pas le nombre de PoP qu’un fournisseur exploite au niveau mondial, mais la densité de sa couverture dans les régions où vivent vos utilisateurs et vos applications, et le fait que ces PoP traitent le trafic dans le cadre de la juridiction appropriée.

Pour les organisations européennes, cela signifie qu’il faut poser des questions spécifiques. Où se trouvent les points de contact dans les régions du Benelux, du DACH et des pays nordiques ? Les inspections de sécurité, y compris le décryptage TLS, sont-elles effectuées à l’intérieur des frontières de l’UE ? Où sont stockés les journaux ? Qui exploite l’infrastructure et sous quelle législation ? Un fournisseur basé en Europe comme Jimber répond à ces questions par défaut : le trafic reste dans la juridiction de l’UE parce que l’entreprise et son infrastructure opèrent sous la législation de l’UE.

Modèles de déploiement SASE

Il n’existe pas de méthode unique pour déployer SASE. L’architecture supporte plusieurs modèles, chacun avec des compromis qui dépendent de la taille de l’organisation, des investissements existants et des exigences de conformité.

SASE à fournisseur unique

Un seul fournisseur fournit les composants de réseau (SD-WAN) et de sécurité (SSE) sous la forme d’une plateforme unifiée. Les avantages sont les suivants : un seul plan de gestion, un seul modèle de données, une application cohérente des politiques et aucune complexité d’intégration entre les fournisseurs. La contrepartie est le risque de verrouillage des fournisseurs et le fait qu’aucun fournisseur n’est leader dans toutes les capacités.

Gartner prévoit que 50 % des nouveaux déploiements de SASE se feront avec un seul fournisseur d’ici 2028, contre environ 30 % en 2025. Toutefois, les données actuelles sur l’adoption montrent que seulement 17 % des entreprises utilisent un seul fournisseur aujourd’hui, 58 % d’entre elles s’appuyant encore sur trois fournisseurs ou plus. L’écart entre les aspirations et la réalité est important.

Pour les entreprises de taille moyenne, le SASE à fournisseur unique présente un avantage certain : la simplicité. Avec deux à cinq informaticiens gérant l’ensemble de l’environnement, les frais opérationnels liés à la coordination de plusieurs fournisseurs sont proportionnellement beaucoup plus élevés que pour les équipes d’entreprise disposant de groupes dédiés à la mise en réseau et à la sécurité. Les plateformes à fournisseur unique ont également tendance à se déployer plus rapidement, ce qui est important lorsque l’alternative est un projet d’intégration de plusieurs mois. La plateforme Jimber est construite autour de ce principe : ZTNA, SWG, FWaaS, SD-WAN et posture de l’appareil dans une seule console, avec des délais de déploiement mesurés en semaines plutôt qu’en trimestres.

SASE à double fournisseur

SD-WAN d’un fournisseur et SSE d’un autre, intégrés via des API et des tunnels. Cette approche est courante dans les organisations qui ont déjà investi dans le SD-WAN et qui souhaitent ajouter la sécurité dans le nuage sans démanteler l’infrastructure existante. Cette approche offre une certaine flexibilité et une sélection des meilleures capacités. La contrepartie est la séparation des plans de gestion, un dépannage plus complexe et le risque d’une application incohérente des politiques entre les deux plateformes.

SASE géré par des partenaires de service

Un partenaire de service conçoit, déploie et exploite l’architecture SASE pour le compte du client. Les données du secteur montrent que plus de 80 % des organisations font appel à des partenaires externes pour la mise en œuvre de SASE. Pour les entreprises de taille moyenne dont les capacités internes sont limitées, ce modèle permet d’accélérer le retour sur investissement et de réduire la charge de travail du personnel chargé d’exploiter la plateforme au jour le jour.

La contrepartie est un contrôle direct réduit et une dépendance à l’égard de l’expertise du partenaire. Le choix d’une plateforme conçue pour des opérations multi-locataires, avec une tarification transparente et des outils clairs pour les partenaires, atténue ce risque de manière significative. L’architecture de Jimber est conçue pour privilégier les partenaires : gestion multi-tenant, automatisation basée sur les API, et un modèle de tarification qui donne aux partenaires des marges prévisibles sur l’ensemble de leur base de clients.

SASE hybride

Combine les SASE fournis dans le nuage avec des appareils sur site pour des cas d’utilisation spécifiques. Il s’agit du segment qui connaît la croissance la plus rapide, tiré par les organisations qui ont besoin d’une application locale pour les environnements OT, les exigences en matière de souveraineté des données ou les réseaux à air comprimé. Les déploiements hybrides sont de plus en plus courants dans les secteurs de la fabrication, des soins de santé et des infrastructures critiques, où certains trafics ne peuvent pas quitter une installation.

SASE vs SSE : la différence architecturale

SSE (Security Service Edge) est le sous-ensemble de SASE consacré uniquement à la sécurité. Il comprend le SWG, le CASB, le ZTNA et le FWaaS, mais pas le SD-WAN. Gartner a introduit la catégorie SSE en 2021 et publie des quadrants magiques distincts pour les plates-formes SSE et SASE.

Cette distinction est importante pour une raison pratique. L’ESS sécurise le trafic mais ne gère pas la manière dont ce trafic atteint la pile de sécurité. Si votre entreprise dispose déjà d’un déploiement SD-WAN fonctionnel et qu’elle a simplement besoin d’ajouter une sécurité fournie par le cloud, SSE peut suffire. Si vous remplacez une infrastructure MPLS vieillissante, si vous repartez à zéro ou si vous souhaitez un plan de gestion unique pour les utilisateurs distants et les succursales, le SASE est la solution la plus complète.

L’orientation à long terme de Gartner favorise la convergence totale. Le raisonnement est le suivant : les décisions en matière de réseau et de sécurité sont de plus en plus souvent les mêmes. L’acheminement efficace du trafic et son inspection cohérente nécessitent le même contexte concernant les utilisateurs, les appareils et les applications. La séparation de ces fonctions dans des plateformes différentes réintroduit la complexité d’intégration que SASE a été conçu pour éliminer. Pour une analyse détaillée des liens entre SASE, SSE et SD-WAN, consultez la comparaison SASE vs SSE vs SD-WAN.

Considérations européennes : souveraineté des données et NIS2

Les organisations européennes qui évaluent l’architecture SASE sont confrontées à deux questions que la plupart des fournisseurs n’abordent pas. Ces deux questions ont des implications architecturales, et pas seulement des implications de conformité.

Où se déroule l’inspection TLS ?

Les plateformes SASE terminent les connexions TLS à leurs points de présence. Cela signifie que le trafic est décrypté, inspecté et recrypté sur une infrastructure exploitée par le fournisseur. Si ces points de présence sont exploités par une société ayant son siège aux États-Unis, ces données peuvent être soumises à la loi américaine CLOUD Act, quel que soit l’endroit où le point de présence est physiquement situé. Un PoP situé à Francfort et exploité par un fournisseur américain ne garantit pas automatiquement la souveraineté des données européennes.

Il ne s’agit pas d’une préoccupation théorique. L’article 32 du GDPR exige des mesures de sécurité appropriées, et l’inspection du trafic crypté pour détecter les menaces est une mesure de sécurité légitime et sans doute nécessaire. Mais le même règlement exige que les données à caractère personnel soient traitées légalement et protégées contre tout accès non autorisé. L’exécution d’une inspection TLS par l’intermédiaire d’une infrastructure soumise aux lois sur le renseignement étranger crée une tension que les conseils d’administration et les DPD souhaitent de plus en plus résoudre.

D’un point de vue architectural, la réponse réside dans les plateformes SASE exploitées par des fournisseurs ayant leur siège en Europe, où le trafic est traité, inspecté et enregistré entièrement au sein de la juridiction de l’UE. Cela élimine l’exposition au CLOUD Act tout en permettant l’inspection de sécurité exigée par le GDPR. Jimber, en tant qu’entreprise belge, fournit cela par défaut. L’inspection du trafic, l’enregistrement et l’application de la politique se font à l’intérieur des frontières de l’UE parce que l’entreprise elle-même opère sous la loi de l’UE. Il n’y a pas de juridiction secondaire à craindre.

Le marché dans son ensemble est en train de rattraper cette réalité. Gartner prévoit que l’Europe dépassera l’Amérique du Nord en termes de dépenses consacrées à l’informatique dématérialisée souveraine d’ici 2027. Plusieurs fournisseurs ayant leur siège aux États-Unis ont réagi en lançant des lignes de produits « souverains », mais il s’agit d’ajouts à des architectures qui n’ont pas été conçues avec la souveraineté des données européennes comme point de départ. Pour les organisations où la juridiction est importante, la distinction entre la souveraineté par conception et la souveraineté par ajout est significative.

Que demande NIS2 à votre architecture ?

Le NIS2 s’applique aux organisations comptant au moins 50 employés ou réalisant un chiffre d’affaires annuel supérieur à 10 millions d’euros et opérant dans des secteurs essentiels ou importants. Cela correspond directement au segment du marché intermédiaire où l’adoption des SASE connaît la croissance la plus rapide. Plus de 160 000 organisations dans l’UE devraient entrer dans le champ d’application.

Le préambule 89 de la NIS2 fait spécifiquement référence aux principes de la confiance zéro, ce qui fait de ZTNA une réponse architecturale directe à une exigence réglementaire, et pas seulement une amélioration de la sécurité. Au-delà de la confiance zéro, NIS2 exige la notification des incidents dans les 24 heures (la journalisation centralisée de SASE y contribue), la surveillance continue de la sécurité (DEM et analyses y contribuent), la gestion des risques avec des contrôles documentés (la gestion unifiée des politiques y contribue), la sécurité de la chaîne d’approvisionnement (SASE étend une politique cohérente à l’accès des tiers) et la segmentation du réseau (la microsegmentation par ZTNA et l’isolation en ligne y contribuent).

L’approche de Jimber, basée sur une console unique, rend la collecte de preuves NIS2 pratique pour les équipes informatiques réduites. Les versions des politiques, les journaux d’accès, les enregistrements de l’état des appareils et les calendriers des incidents sont regroupés sur une seule plateforme, prête à être exportée lorsque l’auditeur vous appelle. Pour une préparation pratique à l’audit, consultez la liste de contrôle de la conformité NIS2 pour les responsables informatiques.

Comment Jimber aborde l’architecture SASE

Jimber propose Real SASE dans une plateforme unique gérée dans le cloud et conçue pour les organisations européennes du marché intermédiaire et les partenaires de service qui les soutiennent. La plateforme unifie ZTNA, SWG, FWaaS, SD-WAN et la vérification de la posture des appareils dans une seule console. Les politiques sont définies une seule fois et appliquées de manière cohérente aux utilisateurs distants, aux succursales, aux applications en nuage et aux appareils sans agent.

Trois décisions architecturales distinguent Jimber des fournisseurs américains qui dominent le marché des SASE.

La souveraineté européenne en matière de données est intégrée à l’architecture. En tant que fournisseur belge de SASE, Jimber traite, inspecte et stocke les données dans la juridiction de l’UE, éliminant ainsi l’exposition à la loi CLOUD par conception, et non par ajout.

La sécurité des appareils sans agent est une préoccupation de premier ordre, et non une réflexion après coup. Le matériel NIAC fournit une isolation en ligne pour les imprimantes, les capteurs IoT, les systèmes de gestion des bâtiments et les équipements industriels. Ces appareils obtiennent leurs propres politiques microsegmentées, une surveillance comportementale et des flux de communication contrôlés, le tout géré à partir de la même console que les politiques d’accès des utilisateurs. Pour les organisations ayant des environnements IT et OT mixtes, il s’agit du pont sécurisé entre l’IT et l’OT que la plupart des fournisseurs de SASE n’abordent tout simplement pas.

La transparence des prix élimine les barrières commerciales qui freinent l’adoption par les entreprises de taille moyenne. Une tarification par utilisateur, sans surcharge de bande passante, sans ajouts cachés, et des structures de marge claires pour les partenaires de service. Les projections de TCO sur trois ans sont donc simples, comme l’a démontré un gestionnaire de fortune belge qui a réduit ses coûts de sécurité de 58% après avoir remplacé un système fragmenté par la plateforme unifiée de Jimber.

Prêt à voir comment l’architecture SASE fonctionne en pratique dans votre environnement ? Réservez une démonstration et bénéficiez d’une visite personnalisée de la plateforme.

FAQ

Quelles sont les cinq composantes essentielles de SASE ?

Les cinq composants définis par Gartner en 2019 sont le SD-WAN, le Zero Trust Network Access (ZTNA), le Secure Web Gateway (SWG), le Firewall-as-a-Service (FWaaS) et le Cloud Access Security Broker (CASB). Les plateformes modernes de 2025-2026 ajoutent généralement l’isolation du navigateur à distance, la prévention de la perte de données, la surveillance de l’expérience numérique et la sécurité DNS.

En quoi les SASE diffèrent-ils des ESS ?

Le SSE (Security Service Edge) ne comprend que les composants de sécurité : SWG, CASB, ZTNA et FWaaS. Le SASE ajoute le réseau SD-WAN au SSE. Si vous avez besoin à la fois d’une connectivité sécurisée entre les sites et d’une sécurité dans le nuage pour les utilisateurs, vous avez besoin d’un SASE complet. Si vous disposez déjà d’un SD-WAN fonctionnel et que vous n’avez besoin que d’une sécurité dans le nuage, le SSE peut suffire.

Comment SASE sécurise-t-il les appareils qui ne peuvent pas exécuter d’agents ?

Les appareils tels que les imprimantes, les capteurs IoT et les équipements industriels se connectent via une appliance d’isolation en ligne dédiée. Le matériel NIAC de Jimber remplit exactement cette fonction : il s’interpose entre l’appareil sans agent et le reste du réseau, identifie les appareils grâce à des empreintes digitales pilotées par l’IA, applique des politiques de microsegmentation les limitant aux seuls flux de communication désignés, et surveille le comportement pour détecter les anomalies. Aucun logiciel ne doit être installé sur l’appareil lui-même. NIAC constitue donc une passerelle pratique entre les environnements IT et OT, sans perturber la production.

L’architecture SASE est-elle adaptée aux entreprises de taille moyenne ?

Oui. L’adoption par le marché intermédiaire croît plus rapidement que l’adoption par les entreprises, les données du secteur montrant une croissance prévue de l’adoption de plus de 120 % parmi les PME et les entreprises du marché intermédiaire. Le SASE à fournisseur unique est particulièrement bien adapté aux entreprises de 50 à 400 utilisateurs et aux petites équipes informatiques, car il élimine la prolifération des outils et la complexité de l’intégration qui consomment des ressources disproportionnées à cette échelle. La plateforme Jimber est spécialement conçue pour ce segment : une console unique, une tarification transparente et un déploiement en quelques semaines au lieu des projets de plusieurs mois typiques des fournisseurs de SASE d’entreprise.

Combien de temps dure le déploiement de SASE ?

Cela dépend du modèle. Les déploiements à l’échelle de l’entreprise avec deux fournisseurs peuvent prendre de 12 à 18 mois. Les SASE à fournisseur unique pour les entreprises de taille moyenne peuvent aller de la configuration initiale à la protection des premiers utilisateurs en quelques jours ou semaines, avec un déploiement complet sur tous les sites en 6 à 12 semaines. L’approche progressive de Jimber est typique : commencez par ZTNA pour un groupe pilote, étendez la couverture des applications, puis ajoutez SD-WAN pour la connectivité des succursales. Une société belge de gestion de patrimoine a réalisé une migration complète en huit semaines.

SASE remplace-t-il les pare-feu ?

SASE remplace le matériel de pare-feu sur site dans les succursales. Le FWaaS offre une protection équivalente à partir du nuage avec une gestion centralisée. Certaines organisations conservent des pare-feux périmétriques dans les centres de données pour contrôler le trafic nord-sud pendant la transition, mais l’orientation architecturale à long terme est la consolidation complète de la sécurité dans le nuage.

Que doivent rechercher les organisations européennes dans un fournisseur de SASE ?

Cinq critères sont les plus importants. Couverture des points de contact européens avec inspection du trafic au sein de l’UE. La juridiction du siège du fournisseur, qui détermine l’exposition juridique en vertu de la loi américaine CLOUD Act ou de lois étrangères similaires sur l’accès. Capacités de journalisation et de reporting alignées sur NIS2. Inspection TLS conforme au GDPR avec des contrôles de confidentialité appropriés. Et une tarification transparente qui facilite l’approvisionnement pour le secteur public et les industries réglementées. Jimber répond à ces cinq critères de par sa conception : Siège social en Belgique, traitement des données uniquement dans l’UE, enregistrement centralisé des audits et modèle de tarification prévisible par utilisateur.