Le pitch : on a déjà la meilleure sandbox… et on l’ignore
Si tu as déjà lancé un agent “local” façon Claude Cowork / container / VM, tu connais la chanson : plusieurs Go à télécharger, des permissions à gérer, une surface d’attaque qui grossit, et une friction énorme pour l’utilisateur.
Et si la sandbox la plus mature de l’histoire de l’informatique était… déjà installée sur le poste de tes clients ?
C’est l’idée de “The browser is the sandbox”, reprise par Simon Willison à partir des notes de Paul Kinlan : depuis ~30 ans, les navigateurs sont conçus pour exécuter du code hostile et non fiable (celui du web) en limitant au maximum ses dégâts. On clique un lien, on exécute du code venu de nulle part, et pourtant la plupart du temps ton OS survit.
Le twist : cette capacité est exactement ce qu’il manque aux agents IA pour agir sur des fichiers, appeler des APIs, et automatiser des tâches… sans transformer ton laptop en labo de cybersécurité.
Dans cet article, on va voir :
- pourquoi le navigateur est une sandbox “prête à l’emploi” pour des agents
- les 3 piliers (fichiers, réseau, exécution sûre) et comment le web les gère
- ce que montre le prototype Co-do (inspiré de Cowork)
- des cas d’usage concrets pour entrepreneurs/PME
- les limites (sans bullshit) et comment les contourner
Sources principales : Simon Willison (25 jan 2026) et les notes de Paul Kinlan sur le sandboxing navigateur, plus quelques signaux récents sur l’isolation navigateur (Cloudflare, Firefox, études V8).
Pourquoi ça compte pour toi (entrepreneur, freelance, PME)
Un agent IA utile, ce n’est pas un chatbot. C’est un système qui :
- lit tes fichiers (docs, contrats, CSV, code)
- appelle des APIs (CRM, facturation, e-mail, Slack)
- exécute du code (parser, transformer, générer)
Le problème : dès que tu donnes ces pouvoirs à un agent, tu dois lui donner un bac à sable solide. Sinon tu te retrouves avec :
- des clés API qui fuitent
- un agent qui lit “trop” de fichiers
- du code généré qui fait n’importe quoi
- un modèle qui exfiltre des données via le réseau
Les gros résolvent ça avec des environnements lourds : conteneurs, VM, RBAC, EDR, etc. Très bien… si tu es une banque.
Toi tu veux : un truc qui marche, rapide à déployer, et qui ne te coûte pas 30k€ de “conseil sécurité” pour un POC.
Le navigateur : une sandbox construite pour exécuter du code hostile
Le navigateur moderne, c’est :
- un modèle de sécurité basé sur l’origine (same-origin)
- des permissions explicites
- des processus isolés
- une surface d’accès système volontairement limitée
Et ça continue de se durcir. Exemple : Firefox a récemment renforcé son Content Process Sandbox sur Windows (niveau 9) et son GPU Process Sandbox (niveau 2), visant un verrouillage plus strict de certaines APIs système (retours communautaires, début 2026).
Côté entreprise, Cloudflare pousse l’idée que le navigateur est un cauchemar pour les RSSI car il exécute en permanence du code étranger — et vend de l’isolation distante (RBI) comme réponse. Matthew Prince résume bien le problème : à chaque page, tu télécharges et exécutes du code tiers (Wired, via Cloudflare). Moralité : l’industrie investit massivement dans l’isolation navigateur.
Le marché de l’isolation de navigateur (RBI) est d’ailleurs annoncé en forte croissance : certains rapports parlent de 0,59 Md$ (2024) → 5,35 Md$ (2032) avec ~31,75% de CAGR (Datam Intelligence via Business Herald). Même si tu prends ces chiffres avec prudence (les études de marché adorent gonfler), la tendance est claire : le navigateur devient un périmètre de sécurité central.
Les 3 piliers d’une sandbox pour agents (et comment le web les adresse)
Paul Kinlan découpe le problème en trois : filesystem, réseau, exécution sûre. C’est exactement ce que tu dois maîtriser pour faire un agent “opérationnel”.
1) Accès fichiers : donner juste assez, pas trop
Deux approches côté navigateur :
- File System Access API : accès plus riche (lecture/écriture) mais encore très dépendant de Chrome (au moment où Simon Willison écrit).
- `<input type="file" webkitdirectory>` : permet de sélectionner un dossier entier et de donner un accès lecture seule au navigateur. Surprise utile : ça marche sur Firefox, Safari et Chrome d’après l’expérience rapportée (et testée par Willison).
Implication pratique : pour beaucoup de cas d’usage “agent sur tes docs”, le mode lecture seule suffit largement et évite d’ouvrir la porte à des dégâts.
Exemples concrets :
- analyser un dossier de factures PDF/CSV et produire un rapport
- parcourir un repo de code et générer une doc
- lire un répertoire de contrats et extraire des clauses
2) Accès réseau : autoriser seulement ce que tu veux
Le réseau est le vecteur d’exfiltration numéro 1. Si ton agent peut appeler n’importe quel domaine, il peut aussi envoyer tes données n’importe où.
Les outils web utiles ici :
- CSP (Content Security Policy) : tu listes explicitement les domaines autorisés (LLM provider, API interne, etc.).
- `<iframe sandbox>` : tu exécutes l’app/agent dans un iframe avec des capacités réduites.
Point important (et trop rarement traité) : la documentation de <iframe sandbox> est… mince, et les comportements varient. Kinlan détaille une technique double-iframe pour appliquer des règles réseau strictes à l’iframe interne (d’après le résumé de Willison). C’est le genre de détail qui fait la différence entre “démo sympa” et “outil utilisable”.
3) Exécution sûre : WASM + Web Workers
Même si tu limites fichiers et réseau, tu veux éviter que du code généré par l’agent puisse :
- geler l’UI
- accéder à des APIs non prévues
- exploiter une faille du moteur JS
Une approche : WebAssembly (WASM) exécuté dans des Web Workers.
- Worker = isolation + pas de blocage UI
- WASM = exécution performante, surface plus contrôlable
Attention : “plus contrôlable” ne veut pas dire invulnérable. Une étude académique récente sur V8 mentionne avoir identifié 19 bugs permettant de contourner des mécanismes d’isolation (arXiv 2025). Donc oui, le navigateur est une sandbox robuste… mais pas magique.
Co-do : une preuve par l’exemple (agent sur fichiers + LLM + sandbox)
Le prototype Co-do (construit par Kinlan) teste l’hypothèse “Cowork-like dans le navigateur”. Le flow est simple :
- tu sélectionnes un dossier de fichiers
- tu configures un provider LLM + clé API
- l’app fournit un chat + des “tools” pour interagir avec les fichiers
- les appels réseau passent par des règles CSP strictes
Le ressenti décrit par Willison : ça ressemble à Claude Cowork, sans conteneur local multi-Go.
Pour un entrepreneur, c’est énorme : tu peux livrer un agent “sur les docs du client” via une simple URL, avec une sandbox raisonnable, et une friction quasi nulle.
Cas d’usage concrets (ce que tu peux builder dès maintenant)
1) “Agent de clôture comptable” dans le navigateur
- Input : dossier
2025-12/avec factures, exports Stripe, relevés - Action : l’agent classe, détecte anomalies, prépare écritures
- Output : un CSV propre + un rapport
Pourquoi navigateur : lecture seule via webkitdirectory, zéro install, CSP qui autorise uniquement ton endpoint + le LLM.
2) “Agent QA” pour solopreneur SaaS
- Input : dossier
support_tickets/exporté - Action : cluster des tickets, propose FAQ, rédige réponses
- Output : markdown prêt à publier
Bonus : tu peux faire tourner des parsers en WASM (rapide) dans un Worker.
3) “Agent d’audit de contrats” pour PME
- Input : dossier de contrats
- Action : extraction clauses (durée, résiliation, indexation), alerte sur risques
- Output : table + résumé
Le point clé : tu gardes les documents sur la machine. Tu n’uploades pas forcément tout, tu peux n’envoyer au LLM que des extraits nécessaires.
Les limites (et comment ne pas se mentir)
Limite 1 : les APIs ne sont pas uniformes
- File System Access API : encore très Chrome-centric.
<iframe sandbox>: doc faible, comportements différents.
Stratégie : vise d’abord le plus portable (webkitdirectory en lecture seule) et ajoute les features “write” en option.
Limite 2 : la sandbox navigateur n’est pas inviolable
Des failles existent (moteur JS, GPU, etc.). Les navigateurs se durcissent (Firefox niveau 9, etc.) mais zéro risque n’existe pas.
Stratégie :
- principe du moindre privilège (fichiers minimaux, réseau minimal)
- pas de secrets longs en clair côté client
- rotation de clés + scopes API
- logs côté serveur sur les appels sortants autorisés
Limite 3 : le modèle économique LLM côté client
Si tu mets la clé API LLM dans le navigateur, tu dois gérer :
- fuite potentielle
- abus (quota explosé)
Stratégie : proxy serveur avec jetons courts, quotas par session, ou clé utilisateur si tu es en B2B interne.
Le playbook Deepthix : comment l’utiliser pour automatiser sans container
Si tu veux un plan d’action concret :
- Commence par un agent “read-only” : sélection de dossier + extraction + rapport.
- Verrouille le réseau : CSP qui n’autorise que
api.deepthix.com+ ton provider LLM. - Découpe tes outils : un tool = une action (lister fichiers, lire, chercher, résumer). Pas un “super tool” fourre-tout.
- Exécute le lourd dans un Worker : parsing, embeddings locaux (si tu en fais), transformations.
- Mesure : temps gagné, erreurs, coûts tokens. Tu itères.
C’est pragmatique, ça évite les usines à gaz, et ça respecte ce que veulent tes clients : du résultat, vite.
Conclusion : le navigateur n’est pas “un endroit où on consulte des pages”
Le navigateur est déjà un runtime sécurisé, multi-plateforme, déployé partout, et conçu pour exécuter du code non fiable. Pour les agents IA, c’est une opportunité énorme : livrer des automatisations utiles sans conteneurs lourds et sans onboarding pénible.
Tu ne vas pas remplacer toutes les sandboxes serveur avec ça. Mais pour 80% des besoins opérationnels d’une PME (analyse de docs, préparation de livrables, QA, tri, reporting), c’est un sweet spot.
Tu veux automatiser tes opérations avec l'IA ? Réserve un call de 15 min pour en discuter.