Aujourd’hui, nous passons notre vie sur le web. Nous cliquons sur des liens sans trop réfléchir, nous ouvrons des pièces jointes suspectes, nous visitons des sites inconnus. Pourtant, à chaque fois, nous exposons plus ou moins directement notre ordinateur, nos fichiers, nos mots de passe, toute notre vie numérique.
Et si la solution la plus simple était aussi la plus radicale : ne jamais laisser le web toucher vraiment notre machine ?
Le bac à sable : une vieille idée qui reste très pertinente
Le principe existe depuis longtemps. Les navigateurs modernes isolent déjà chaque onglet dans son propre processus avec des droits très limités. C’est ce qu’on appelle le sandboxing natif.
Voici un schéma classique de l’architecture multi-processus de Chrome (Chromium), montrant clairement le browser process (non sandboxé) qui gère l’interface et les renderer processes (sandboxés) qui exécutent le contenu web :
Architecture multi-processus de Chromium : isolation des renderer processes
Mais quand on regarde de près, on se rend compte que ce n’est pas toujours suffisant :
- une vulnérabilité zero-day bien ciblée peut parfois s’échapper du bac à sable
- certains malwares attendent patiemment que l’utilisateur effectue une action donnant plus de privilèges
- les attaques côté navigateur deviennent de plus en plus sophistiquées (WebGPU, WebAssembly, etc.)
Alors de plus en plus de gens se posent la question : et si on allait plus loin ? Et si on faisait tourner le navigateur entier ailleurs ?
La navigation à distance, ou « Je regarde, mais ne touche pas »
L’idée est simple sur le papier : le vrai navigateur tourne sur un serveur distant (dans le cloud, dans un conteneur, dans une machine virtuelle…), et sur votre écran vous ne recevez qu’une image animée en temps réel.
Vous cliquez → l’événement est envoyé au serveur Le serveur déplace la page → il vous envoie la nouvelle image
Techniquement, c’est du streaming vidéo bidirectionnel avec très faible latence. WebRTC est devenu la star pour ça : c’est la même technologie qui fait fonctionner Google Meet, Discord, ou le cloud gaming.
Voici un schéma simplifié expliquant le flux d’isolation de navigateur à distance :
Flux de données dans une architecture de navigation isolée à distance
Exemples concrets émergents
Les cas d’usage sont nombreux et variés :
- Entreprises : donner aux employés un « navigateur fantôme » pour les tâches sensibles (banque en ligne, messagerie professionnelle, sites administratifs)
- Équipes de sécurité : ouvrir des pièces jointes ou des URLs suspectes dans un navigateur jetable
- Familles : laisser les enfants naviguer sans risquer de tout casser
- Chercheurs : tester des malwares sans contaminer leur laboratoire
Solutions commerciales existantes
Il existe déjà des solutions sur le marché aujourd’hui :
Menlo Security
Une des pionnières en isolation de navigateur à distance cloud-native, avec une isolation invisible et performante.
→ https://www.menlosecurity.com/
Ericom Shield
Isolation zero-trust pour le web et les e-mails, rendu dans des conteneurs cloud.
→ https://www.ericom.com/remote-browser-isolation
Zscaler Browser Isolation
Transforme le contenu web en flux de pixels sécurisé, intégré à leur plateforme Zero Trust.
→ https://www.zscaler.com/products-and-solutions/browser-isolation
Cloudflare Browser Isolation
Isolation cloud avec plusieurs modes (pixel pushing, reconstruction DOM, etc.).
→ https://www.cloudflare.com/learning/access-management/what-is-browser-isolation
Solutions open-source
Neko (n.eko)
Il y a aussi Neko, un projet open-source super intéressant et auto-hébergé :
- navigateur virtuel qui tourne dans un conteneur Docker
- utilise WebRTC pour streamer l’affichage en temps réel (vidéo + audio + interactions)
- chaque session est isolée : parfait pour de la navigation jetable, sans traces locales
- supporte plusieurs navigateurs (Firefox, Chrome, Brave, Tor, etc.)
- idéal pour du visionnage collaboratif, des tests sécurisés, ou naviguer anonymement depuis n’importe quel appareil
→ Repo GitHub : https://github.com/m1k1o/neko → Documentation officielle : https://neko.m1k1o.net/
C’est souvent comparé à un clone moderne de Rabb.it, mais avec un focus sur la sécurité et l’isolation. Beaucoup l’utilisent en auto-hébergé sur un VPS ou un NAS pour avoir leur propre « navigateur fantôme » privé.
BrowserMania (Projet académique)
Puis il y a des projets plus expérimentaux, comme BrowserMania (un projet étudiant/académique récent) qui pousse l’idée assez loin :
- chaque session tourne dans son propre conteneur Docker
- Kubernetes orchestre tout : création, destruction, mise à l’échelle automatique
- WebRTC envoie l’image et récupère les clics/souris/clavier
- à la fin de la session → le conteneur est supprimé, zéro trace
Architecture technique détaillée
Voici un aperçu de l’architecture technique d’une solution d’isolation cloud-native :
Architecture cloud-native avec orchestration Kubernetes
C’est lourd, ça consomme des ressources serveur, mais pour des usages critiques, c’est très efficace.
Les inconvénients qu’on ne peut pas ignorer
Comme toute technologie, il y a des compromis :
1. La latence
Même avec une bonne connexion, on sent parfois le décalage (surtout pour taper vite ou scroller rapidement). Le streaming de jeux vidéo a le même problème.
2. La dépendance
Si le serveur tombe, vous ne pouvez plus naviguer. Pas de connexion internet = pas de navigation, même en local.
3. La vie privée
Vos actions passent par un intermédiaire. Même si tout est chiffré de bout en bout (WebRTC utilise DTLS-SRTP), une confiance complète envers l’opérateur de la plateforme reste nécessaire.
Alors, est-ce l’avenir de la navigation ?
Pas pour tout le monde, pas tous les jours. Mais pour certaines situations spécifiques, oui, ça commence à ressembler à une vraie réponse pragmatique.
On est peut-être en train de passer d’une ère où « le navigateur protège mon ordinateur » à une ère où « mon ordinateur ne touche jamais vraiment internet ».
Quand utiliser la navigation isolée ?
✅ Recommandé pour :
- Ouvrir des liens suspects ou pièces jointes douteuses
- Navigation sur des réseaux publics non sécurisés
- Accès à des sites sensibles (banque, admin, santé)
- Environnements de test et développement
- Contextes professionnels avec données critiques
❌ Moins adapté pour :
- Usage quotidien léger (lecture d’articles, YouTube)
- Zones avec connexion internet limitée
- Applications web nécessitant des performances maximales
- Cas où la confidentialité vis-à-vis du fournisseur est critique
Essayez par vous-même
Vous voulez tester ? Voici quelques options :
Option 1 : Docker local (le plus simple)
Si vous voulez juste essayer rapidement avec notre image Docker Chromium :
docker run -d \
--name=chromium_test \
--security-opt seccomp=unconfined \
-e PUID=1000 \
-e PGID=1000 \
-e TZ=Etc/UTC \
-p 3000:3000 \
-p 3001:3001 \
--shm-size="1gb" \
--restart unless-stopped \
dilanek/docker_chromiun:test
Puis ouvrez votre navigateur sur http://localhost:3000
Option 2 : Neko (auto-hébergé complet)
Pour une solution complète auto-hébergée :
git clone https://github.com/m1k1o/neko
cd neko
docker-compose up -d
Option 3 : Architecture complète Kubernetes
Pour un déploiement cloud-native complet, consultez le projet BrowserMania :
→ https://github.com/BrowserMania/Browsermania
Conclusion
La navigation web isolée n’est pas une mode passagère. C’est une réponse technique concrète à des menaces réelles et croissantes.
Les technologies sont matures (WebRTC, conteneurs, orchestration), les performances s’améliorent constamment, et les cas d’usage se multiplient.
La vraie question n’est plus « est-ce que ça marche ? » mais plutôt « pour quels usages ça vaut le coup ? ».
Seriez-vous prêt à naviguer comme ça aujourd’hui ? À laisser le web rester… à l’extérieur ?