Vos équipes accèdent aux applications métier, aux outils SaaS, aux données clients depuis un navigateur. Vos prestataires aussi, depuis des postes que vous ne maîtrisez pas.
La question de fond : quel lien existe entre ces postes et vos applications ? Que peut faire un endpoint compromis ou un individu malveillant une fois connecté à votre SI ?
La réponse dépend de votre architecture d'accès.
Le VPN et le ZTNA : deux générations, même angle mort
Le VPN (Virtual Private Network) a été conçu pour une époque où les applications vivaient dans vos datacenters. Un tunnel chiffré, un accès réseau large. Le collaborateur se connecte, il est "dedans".
Le problème : l'attaquant aussi. D'après le rapport "Orange Security Navigator 2026", les VPN concentrent 55% des accès initiaux aux SI d'entreprise en 2025, que ce soit via un compte compromis (35%) ou l'exploitation directe de l'outil (20%). Une fois connecté, le poste a un accès réseau direct au SI. Mouvement latéral libre.
Le ZTNA (Zero Trust Network Access) corrige ce défaut. Plus d'accès réseau global : chaque utilisateur accède uniquement à l'application autorisée, après vérification d'identité. C'est un progrès réel.
Mais le ZTNA s'arrête à la porte de l'application. Le poste a toujours un accès direct à l'application cible. Un attaquant peut attaquer l'application, ses API, exfiltrer des données, exploiter l'application comme pivot. Le ZTNA contrôle qui accède. Pas ce que le poste peut faire une fois connecté.
L'étape suivante : Utilisez une solution de Secure Enterprise Browsing
Le marché a identifié ce chaînon manquant. Les analystes convergent vers une nouvelle catégorie : les solutions de Secure Enterprise Browsing (SEB).
Le principe : maîtriser le lien entre le poste et l'application. Contrôler ce que l'utilisateur peut faire dans sa session, indépendamment de l'état de son endpoint.
Une solution SEB applique les principes Zero Trust directement à la session de navigation :
- Vérification continue de l'identité et du contexte
- Contrôle granulaire des actions (copier-coller, impression, upload, capture d'écran)
- Protection des applications contre les endpoints compromis
- Visibilité sur l'activité utilisateur
Toutes les solutions SEB ne se valent pas
La catégorie SEB regroupe des approches très différentes. Et la différence est structurelle, pas cosmétique.
La question clé : quel lien reste entre le poste et l'application ?
Les extensions de navigateur
Les solutions agent-based ajoutent une couche de sécurité au navigateur existant (Chrome, Edge, Firefox) via une extension.
Le poste accède directement à l'application. L'extension observe et applique des politiques par-dessus. Mais le lien est direct : le navigateur local charge le DOM, exécute le JavaScript, stocke les cookies. Un poste compromis a accès à tout ce que le navigateur voit, données applicatives comprises.
Autre limite : l'extension doit être installée sur chaque poste. Pour vos collaborateurs sur postes maîtrisés, c'est gérable. Pour un prestataire, un freelance, un partenaire sur son propre équipement ? Il faut convaincre un tiers d'installer un composant de sécurité sur son poste et donc intégrer ce paramètre au contrat. Friction, délais, et parfois refus.
Zero Trust déclaratif : on vérifie l'identité, puis on laisse le poste interagir directement avec l'application.
Les navigateurs durcis (Enterprise Browser)
Un navigateur dédié, durci et contrôlé par l'entreprise.
L'environnement est plus maîtrisé. Mais le lien fondamental ne change pas : le poste accède directement à l'application. Un malware sur le endpoint peut toujours exploiter cette connexion directe.
Le frein opérationnel est encore plus marqué : il faut installer un navigateur complet sur chaque poste. Pour les populations non maîtrisées (tiers, prestataires, freelances) c'est même plus impactant qu'une extension. Imposer un navigateur à des utilisateurs, c'est imposer une conduite du changement, de la formation et du contrôle.
Zero Trust déclaratif : l'environnement est durci, mais le poste reste le point d'accès à l'application.
L'isolation du navigateur - La seule vraie rupture protocolaire
VirtualBrowser rompt le lien entre le poste et l'application. La navigation s'exécute sur un serveur isolé. Le poste reçoit un flux vidéo. Rien d'autre.
Les solutions SEB protègent le navigateur. VirtualBrowser protège du navigateur.
Le poste ne touche jamais l'application. Un poste compromis ou un attaquant ne peut attaquer ni l'app, ni ses API, ni exfiltrer des données, ni pivoter vers d'autres zones du SI. Il n'y a pas de connexion à exploiter.
Côté onboarding, le contraste est net. 100% agentless. Pas d'extension à installer, pas de navigateur à déployer. Un prestataire, un freelance, un partenaire ouvre une URL depuis n'importe quel navigateur et travaille immédiatement. BYOD, poste non géré, équipement inconnu, même traitement. L'application et le SI sont protégés, quel que soit l'état du endpoint.
Zero Trust structurel : le risque est neutralisé avant d'atteindre l'application. Par conception, pas par configuration.
VirtualBrowser : couper le lien entre les postes non-maitrisés et vos applications
Concrètement, qu'est-ce que ça change au quotidien ?
Accès sans agent. Vos utilisateurs (internes ou externes) accèdent à leurs applications via une URL. Pas d'agent à déployer, pas de navigateur à installer. Un prestataire peut travailler en 2 minutes, depuis n'importe quel poste sans jamais toucher directement votre SI.
Contrôle granulaire de l'usage (DLP). L'accès n'est pas binaire. Vous définissez ce que chaque utilisateur peut faire dans sa session :
- Consultation en lecture seule, avec/sans filigrane dynamique
- Copier-coller entrant autorisé, sortant bloqué
- Upload autorisé, téléchargement interdit
- Impressions interdites
Rupture protocolaire totale. Aucune donnée applicative ne transite vers le poste. Le poste ne peut pas attaquer l'application car il n'y a pas de connexion directe à exploiter. Pas de DOM à manipuler, pas de JavaScript à détourner, pas de cookie à voler. Le SI est isolé du endpoint par conception.
Ce qu'il faut retenir
La sécurisation des accès web a évolué en trois temps : du réseau (VPN), à l'application (ZTNA), à la session (SEB). À chaque étape, le lien entre le poste et les ressources se resserre.
Au sein des SEB, l'approche compte autant que la catégorie. Le critère discriminant : le poste a-t-il un lien direct avec l'application ? Si oui, un endpoint compromis reste une menace pour vos données et votre SI - à des degrés variables. Si non, le risque est neutralisé à la source.
VirtualBrowser fait ce choix. Isolation physique, pixel streaming, rupture totale entre le poste et l'application. Une approche validée par la certification CSPN de l'ANSSI, qui atteste du niveau de sécurité de la solution.
