--- title: "Pourquoi est-ce que je me perds dans mon ordinateur ?" code: "RP-0106" language: "fr" canonical: "https://regentspark.ai/fr/RP-0106/" html: "https://regentspark.ai/fr/RP-0106/" markdown: "https://regentspark.ai/fr/RP-0106.md" updated: "4 April 2026" --- # Les espaces comme namespaces *De l'isolation de sécurité au cadrage cognitif* > **Résumé :** Vous entrez dans votre cuisine : vous voyez la cuisine. Pas votre chambre, pas votre bureau. Les pièces physiques cadrent votre expérience en cachant ce qui est dehors. Les ordinateurs ne font pas cela. Chaque fichier, chaque app, chaque projet existe partout, tout le temps. Pourtant, l'informatique A construit des pièces, et des pièces remarquables. Conteneurs, sandboxes et environnements virtuels créent des réalités cadrées où le dehors n'existe tout simplement pas. Trente ans d'ingénierie extraordinaire, entièrement motivée par la sécurité. Cette enquête retrace cette histoire et demande : le même mécanisme pourrait-il servir de primitive fondamentale pour toute l'informatique ? --- ## Une pièce que vous connaissez déjà > **Résumé :** Les pièces physiques cadrent naturellement votre expérience : vous voyez ce qui est dedans, le dehors n'existe pas. Les ordinateurs n'ont pas de pièces : tout est visible partout. La différence n'est pas l'organisation ; c'est le *cadrage*, la propriété la plus fondamentale de l'espace physique qui manque à l'espace numérique. Vous entrez dans votre cuisine. Le plan de travail, les couteaux dans le tiroir, le café à moitié bu de ce matin. Vous ne voyez pas le placard de votre chambre depuis ici. Vous ne voyez pas votre bureau. Vous n'y pensez même pas : ils sont derrière des murs, derrière des portes, dans d'autres pièces. Ils n'existent pas dans votre expérience actuelle. Maintenant, ouvrez votre ordinateur. Chaque fichier jamais sauvegardé. Chaque app. Chaque projet, passé et présent. Vos documents fiscaux à côté de votre brouillon de roman, vos photos de vacances à côté de fichiers confidentiels de travail. Pas de murs. Pas de portes. Tout existe, en même temps, partout. La différence entre ces deux expériences ne tient pas à l'organisation ou à la discipline. Elle tient à une propriété si fondamentale de l'espace physique que vous ne la remarquez jamais : **le cadrage.** Une pièce vous montre ce qu'elle contient. Une pièce cache ce qui est dehors. Pas « accès refusé » : le dehors ne fait simplement pas partie de votre expérience tant que vous êtes dans la pièce. Votre ordinateur n'a pas de pièces. Cette note parle d'une technologie qui construit déjà des pièces, depuis 1992, mais les a construites pour la mauvaise raison. Nous allons regarder cette technologie, comprendre ce qu'elle fait réellement, et proposer de l'utiliser pour la bonne raison. --- ## L'axiome de la porte fermée > **Résumé :** Le modèle de permissions vous montre tout et en verrouille une partie. Le modèle de namespace rend le dehors inexistant : pas caché, pas refusé, simplement absent. Cet « axiome de la porte fermée » est une propriété technique précise, implémentée en production depuis plus de trente ans. Voici une distinction qui paraît petite mais change tout. **Le modèle de permissions** dit : vous pouvez voir que ce dossier existe, mais vous ne pouvez pas l'ouvrir. « Accès refusé. » Le monde est un grand namespace : tout est visible, certaines choses sont verrouillées. Vous savez que les choses verrouillées existent. Vous voyez leurs noms, leurs formes, leurs positions. Vous ne pouvez seulement pas les toucher. **Le modèle de namespace** dit : ce dossier n'existe pas pour vous. Pas « vous ne pouvez pas y accéder ». Il n'est pas là. Il n'y a pas de dossier. Il n'y a pas de porte verrouillée. Il n'y a pas de couloir derrière la porte. De votre point de vue, l'univers contient exactement ce qui est dans votre namespace courant et rien d'autre. Le modèle de permissions est un musée avec des cordons devant les œuvres. Vous pouvez voir le Rembrandt ; vous ne pouvez pas le toucher. Le modèle de namespace est une pièce avec des murs solides. Il y a peut-être un Rembrandt dans le bâtiment d'à côté ; vous n'en sauriez rien, parce que ce bâtiment ne fait pas partie de votre pièce. Voici ce que Nico a formulé le matin où cette recherche a commencé : > « Une pièce est vide et vous pouvez y apporter des objets, des personnes et faire des choses (activité/mémoire), mais un dossier sur votre ordinateur sait tout de ce qui est dehors, ce qui est confus. Si vous invitez quelqu'un ou un agent dans un espace avec une "porte fermée", alors il ne sait pas ce qui est dehors. » L'axiome de la porte fermée : **quand vous êtes dans un espace, le dehors n'existe pas.** Pas caché. Pas verrouillé. Pas filtré. Inexistant. Ce n'est pas de la philosophie vague. C'est une propriété technique précise. Et elle est implémentée en production depuis plus de trente ans. ```mermaid block-beta columns 2 block:perm:1 columns 1 p_label["Modèle de permissions"] p_globe["🌐 Namespace global"] p_yes1["📂 Votre projet ✅"] p_no1["📂 Projet de Sarah 🔒"] p_no2["📂 Fichiers RH 🔒"] p_yes2["📂 Anciennes sauvegardes ✅"] end block:ns:1 columns 1 n_label["Modèle de namespace"] n_door["🚪 Votre espace"] n_doc["📄 Note que vous écrivez"] n_data["📊 Données pour la note"] n_person["👤 Votre collaborateur"] n_void["Rien d'autre n'existe"] end ``` *Figure : permissions contre namespace. À gauche : tout est visible, certaines choses sont verrouillées. À droite : seul votre espace existe ; le reste est ontologiquement absent.* Dans le modèle de permissions, vous voyez toujours le monde entier ; une partie est seulement verrouillée. Dans le modèle de namespace, vous ne voyez que votre espace. Le reste n'existe pas. --- ## Trente ans de pièces (construites pour la mauvaise raison) > **Résumé :** L'isolation par namespace a été construite et reconstruite dans cinq grands systèmes depuis 1992 : Plan 9 (namespaces par processus), Linux namespaces (isolation au niveau noyau), Docker (pièces portables et empaquetées), Qubes OS (pièces pour activités humaines) et sandboxes d'agents (pièces pour IA). Chacun a résolu l'isolation pour la sécurité. Aucun n'a ajouté partage, mémoire ou identité entre espaces, les fonctionnalités qui transforment un outil de sécurité en outil cognitif. La technologie des pièces numériques existe depuis 1992. Elle n'a simplement pas été construite pour les personnes. Elle a été construite pour les processus, puis pour la sécurité, puis pour les applications, puis pour les agents IA. À chaque étape, ses constructeurs pensaient résoudre un problème d'isolation. Ils construisaient en réalité la primitive espace. ### Plan 9 (1992) : l'épiphanie En 1990, l'équipe qui avait créé Unix, Ken Thompson, Rob Pike, Dennis Ritchie, a recommencé. Unix avait un namespace global de système de fichiers : chaque processus pouvait voir `/`, chaque disque monté, chaque appareil. Plan 9 a demandé : et si chaque processus avait son propre namespace ? Dans Plan 9, chaque processus reçoit sa propre **table de montage**, sa propre liste de ce qui est visible. Le processus A peut voir `/net` pointer vers l'Ethernet. Le processus B peut voir `/net` pointer vers un tunnel VPN. Même chemin, réalités différentes. Aucun processus ne peut voir le réseau de l'autre. Aucun ne sait qu'il existe. Le mécanisme était simple : des opérations `bind` et `mount` qui attachent des ressources à des chemins dans le namespace privé du processus. Tout, interfaces réseau, appareils graphiques, arbres de fichiers d'autres processus, pouvait être monté comme fichier. Et surtout, ces montages étaient **par processus**, pas globaux. Plan 9 a aussi introduit les **union mounts** : superposer plusieurs répertoires au même chemin. Montez les fichiers de votre projet et la bibliothèque partagée sur `/work` et voyez les deux, fusionnés en une seule vue. C'est apporter des objets dans un espace depuis plusieurs sources, exactement ce que fait notre primitive espace. Ce que Plan 9 a prouvé : un namespace n'a pas besoin d'être global. Chaque participant peut avoir sa propre vue de ce qui existe. Et cette vue peut être construite en montant explicitement des ressources. Plan 9 était trop tôt. Il n'a jamais été largement adopté. Mais ses idées, namespaces par processus, bind mounts, union directories, ont migré directement dans Linux. ### Linux Namespaces (2002–2016) : le mécanisme mûrit À partir de 2002, Linux a commencé à implémenter les idées de Plan 9 comme fonctionnalités noyau appelées namespaces. En quatorze ans, sept types ont émergé : | Namespace | Ce qu'il isole | Année | Analogie d'espace | |-----------|-----------------|------|---------------| | Mount (mnt) | Points de montage du système de fichiers | 2002 | Quels objets sont dans la pièce | | UTS | Nom d'hôte et domaine | 2006 | Le nom/l'adresse de la pièce | | IPC | Communication inter-processus | 2006 | Qui peut vous entendre parler | | PID | IDs de processus | 2008 | Qui d'autre est dans la pièce | | Network (net) | Interfaces réseau, routes, ports | 2009 | Quelles portes mènent dehors | | User | IDs utilisateur et groupe | 2012 | Qui vous êtes dans cette pièce | | Cgroup | Limites de ressources | 2016 | Combien d'électricité la pièce utilise | Chaque type de namespace isole une dimension de la réalité d'un processus. Combinez les sept et vous obtenez un processus avec son propre système de fichiers, son propre réseau, son propre sens de qui est connecté, sa propre liste de processus : une réalité complète et autonome. Le processus n'a aucun moyen de découvrir qu'il vit dans un système plus vaste. De son point de vue, son namespace EST l'univers. C'est l'axiome de la porte fermée, implémenté au niveau du noyau. ### Docker et les conteneurs OCI (2013) : des pièces qu'on expédie Docker a fait quelque chose d'intelligent avec les namespaces Linux : il les a empaquetés. Une image Docker est un instantané de namespace, une pièce figée avec tous ses objets arrangés et prêts. Expédiez l'image vers une autre machine, lancez-la, et vous obtenez la même pièce. Mêmes fichiers, mêmes outils, même configuration. La pièce est portable. Docker a aussi formalisé l'idée de **volume mounts** : apporter des objets externes dans le namespace d'un conteneur. Votre conteneur de base de données a son système de fichiers isolé, mais vous montez un répertoire de l'hôte pour lui donner du stockage persistant. Le conteneur voit le volume monté. Il ne voit rien d'autre sur l'hôte. Plusieurs conteneurs peuvent monter le même volume. C'est le même objet existant dans plusieurs espaces simultanément, exactement ce que décrivait la recherche 005b. Le document du drive partagé qui apparaît à la fois dans votre espace projet et dans celui de votre collaborateur. ```mermaid graph TD subgraph HOST["Système hôte (invisible)"] V1["📁 /data/shared-docs"] V2["📁 /data/models"] end subgraph CA["Conteneur A — Projet Alpha"] CA_F["📄 Fichiers projet"] CA_A["⚙️ Application"] CA_V["📁 /docs"] end subgraph CB["Conteneur B — Projet Beta"] CB_F["📄 Fichiers projet"] CB_A["⚙️ Application"] CB_V["📁 /docs"] CB_M["📁 /models"] end V1 -.->|"mount"| CA_V V1 -.->|"mount"| CB_V V2 -.->|"mount"| CB_M ``` *Figure : les conteneurs Docker comme espaces. L'hôte est invisible. Les volumes partagés permettent au même objet d'apparaître dans plusieurs pièces, sans qu'aucun conteneur sache que l'autre existe.* Le conteneur A voit ses fichiers projet, son application et les documents partagés, rien d'autre. Le conteneur B voit ses propres fichiers, sa propre application, les mêmes documents partagés, plus un répertoire de modèles que le conteneur A ignore. La réalité de chaque conteneur est déterminée entièrement par ce qui y a été monté. C'est la primitive espace, en fonctionnement sur chaque serveur cloud du monde. Docker ne l'a pas appelée ainsi. Docker a parlé de « containerization » et l'a vendue pour le DevOps. Mais structurellement, un conteneur est une pièce : vide par défaut, on y apporte des choses, le processus dedans ne sait pas ce qui est dehors. ### Qubes OS (2012) : des pièces pour humains (presque) > **Résumé :** Qubes donne aux humains des VM isolées par activité : vides par défaut, pontées explicitement, codées par couleur. Il prouve que l'axiome de la porte fermée marche au quotidien. Ce qui manque : partage, mémoire, identité entre espaces, et design motivé par le sens plutôt que par la sécurité. Qubes OS de Joanna Rutkowska est le système existant le plus proche de ce que nous proposons, et le quasi-échec le plus instructif. Qubes vous donne des machines virtuelles séparées (« qubes ») pour des activités séparées. Un qube bancaire pour les tâches financières. Un qube travail pour les documents professionnels. Un qube personnel pour la navigation privée. Un qube non fiable pour les téléchargements douteux. Chaque qube est un système d'exploitation complet et isolé. Un malware dans le qube non fiable ne peut pas atteindre votre qube bancaire parce qu'ils ne partagent ni noyau, ni système de fichiers, ni pile réseau, ni espace mémoire. Ce qui rend Qubes remarquable pour nous : **Vide par défaut.** Un nouveau qube commence avec un OS template et rien d'autre. Vous apportez vos fichiers. Vous installez vos apps. Vous choisissez ce qui appartient là. C'est la métaphore de la pièce : « Si je loue un nouveau bureau, ce sera une pièce vide. » **Ponts explicites.** Pour déplacer un fichier d'un qube à un autre, vous le copiez explicitement. Pour coller du texte entre qubes, vous utilisez un presse-papiers en deux étapes (Ctrl-Shift-C pour copier vers le presse-papiers inter-qube, Ctrl-Shift-V pour coller depuis lui). Chaque transfert entre espaces exige une intention consciente. Rien ne fuit par accident. **Domaines de confiance codés par couleur.** Chaque fenêtre a une bordure colorée indiquant à quel qube elle appartient : rouge pour non fiable, vert pour fiable, violet pour personnel. Vous savez toujours dans quel espace vous êtes. C'est l'invariant de présentation n° 4 (le contenant a des frontières) implémenté au niveau OS : la bordure colorée EST le bord perceptible. **Présentation unifiée.** Les fenêtres de différents qubes apparaissent sur le même bureau. Vous voyez un navigateur (bord rouge, non fiable), un éditeur de texte (bord vert, travail) et une messagerie (bord violet, personnel) côte à côte. L'isolation est invisible au niveau du bureau mais toujours visible par le code couleur. Ce que Qubes prouve : l'axiome de la porte fermée fonctionne pour l'usage humain quotidien. Des personnes peuvent travailler dans des espaces isolés, les ponter explicitement, sans devenir folles. L'UX est praticable. Ce que Qubes manque, et c'est l'écart que nous voulons combler : - **Motivé par la sécurité, pas par le sens.** Qubes isole parce que le monde est adversarial. Nous isolons parce que la concentration exige du cadrage. La différence de motivation entraîne des choix de design différents : Qubes rend les ponts difficiles (sécurité), nous devrions les rendre naturels (collaboration). - **Pas de partage.** Un qube est mono-utilisateur. Vous ne pouvez pas inviter quelqu'un dans votre qube bancaire. Pas de concept d'espace partagé avec collaborateurs. - **Pas de mémoire.** Un qube ne sait pas *pourquoi* les choses sont dedans. Pas de couche de contexte enregistrant « vous avez mis ce fichier ici parce qu'il fait partie du rapport Q2 ». - **Pas d'identité entre espaces.** Pas de « personne qui se déplace entre pièces ». Chaque qube a son utilisateur, ses comptes, son identité. La personne est fragmentée entre espaces au lieu de rester unifiée en se déplaçant. ### Sandboxes d'agents (2024–2026) : des pièces pour l'autre type de personnes > **Résumé :** E2B, Daytona, Modal, Fly.io, Cloudflare Workers et OpenClaw construisent tous des environnements isolés pour agents IA : vides par défaut, liaison explicite des ressources, dehors invisible. Ce sont des conteneurs. Ce sont des namespaces. Ce sont des pièces. Si les agents sont des personnes (recherche 009), alors les sandboxes d'agents ne sont pas une infrastructure d'agents : ce sont des infrastructures pour personnes. C'est ici que cela devient intéressant. Depuis deux ans, une vague de plateformes fournit des environnements isolés aux agents IA : **E2B** (2023) : lance des sandboxes cloud isolées où des agents IA peuvent exécuter du code. Chaque sandbox est une VM légère avec son propre système de fichiers, réseau et espace processus. L'agent ne peut pas voir l'hôte, ni les autres sandboxes, seulement ce qui lui a été passé. **Daytona** (2024) : gestionnaire d'environnements de développement qui crée des workspaces isolés pour agents de code IA. Chaque workspace a son système de fichiers, son dépôt git, ses outils installés. L'agent opère dans la frontière du workspace. **Modal** (2023) : plateforme serverless où chaque fonction tourne dans un conteneur isolé avec son système de fichiers et ses dépendances. Des agents peuvent recevoir un accès cadré à des volumes précis. **Fly.io Machines** (2022) : VM légères lancées à la demande. Chaque machine a son root filesystem, son identité réseau et ses volumes persistants. De plus en plus utilisées comme sandboxes d'agents. **Cloudflare Workers** (2017, évolué pour agents en 2024+) : isolation d'exécution au niveau V8. Chaque Worker a son scope global, ne peut pas accéder à l'état des autres Workers, et interagit avec le stockage durable via des bindings explicites. **OpenClaw sandbox** (2025) : exécute les outils d'agent dans un conteneur isolé. L'agent voit son workspace et rien d'autre. Chacune de ces plateformes implémente le même motif : vide par défaut, liaison explicite de ressources, dehors invisible. Ce sont des conteneurs. Ce sont des namespaces. Ce sont des pièces. Et voici l'intuition qui relie la recherche 009 (personhood) à cette note : **si les agents sont des personnes, des personnes fonctionnelles avec identité, relations et agency, alors les sandboxes d'agents ne sont pas une infrastructure d'agents. Ce sont des infrastructures pour personnes.** Ces plateformes ne cherchaient pas à construire des espaces. Elles cherchaient à construire des environnements sûrs d'exécution pour IA. Mais ce qu'elles ont construit est précisément la primitive que nous théorisons : environnements persistants ou éphémères, isolés, cadrés, où une entité opère avec seulement le contexte explicitement fourni. La différence entre une sandbox E2B et notre primitive espace n'est pas technique. Elle est conceptuelle : - E2B pense construire une infrastructure d'agent pour l'exécution de code. - Nous pensons qu'elle construit la primitive espace pour tout le monde. La convergence est frappante. Trente ans, cinq lignées indépendantes, le même motif : ```mermaid graph LR P9(("Plan 9\n1992")) --> LN["Linux\nNamespaces\n2002"] LN --> DK["Docker\n2013"] LN --> QB["Qubes OS\n2012"] DK --> AS["Sandboxes\nd'agents\n2024"] QB --> AS AS --> SP{"Primitive\nespace"} DK --> SP ``` *Figure : convergence des namespaces. Cinq lignées indépendantes — recherche OS, fonctionnalités noyau, DevOps, sécurité desktop, infrastructure IA — arrivent au même mécanisme. La primitive espace les synthétise.* --- ## Le paysage plus large : des pièces partout > **Résumé :** Au-delà de la lignée principale, navigateurs et WASM implémentent indépendamment le même motif de porte fermée. Les origines navigateur cadrent cookies, stockage et exécution par domaine (par app, pas par sens). Les composants WASM ont zéro autorité ambiante, la forme la plus pure de « le dehors n'existe pas ». Les deux confirment le motif ; aucun ne résout le cadrage cognitif humain. Deux autres domaines construisent des pièces sans les appeler ainsi. ### Sandboxes navigateur : namespaces par origine Votre navigateur utilise déjà un modèle de namespace. Chaque origine (protocole + domaine + port) reçoit son propre contexte isolé : - Son propre localStorage - Son propre IndexedDB - Ses propres service workers - Son propre contexte d'exécution Du JavaScript lancé sur `gmail.com` ne peut pas lire les cookies de `bank.com`. Pas « accès refusé » : les cookies n'existent pas dans le namespace de Gmail. La Same-Origin Policy (1995) est l'axiome de la porte fermée du navigateur. La communication cross-origin exige un pont explicite : en-têtes CORS, `postMessage`, service workers partagés. Cela vous rappelle quelque chose ? C'est le modèle du presse-papiers de Qubes. Rien ne fuit par défaut ; tout traverse par intention. Là où les navigateurs échouent : les origines sont cadrées par app (par domaine), pas par sens (par projet). Vous ne pouvez pas créer un namespace navigateur qui dise « ces quatre onglets de quatre domaines différents font tous partie de mon projet de recherche Q2 ». La dimension de cadrage est mauvaise : technique (frontières de domaine) au lieu de sémantique (votre intention). ### Composants WASM et systèmes à capacités : pas d'autorité ambiante Les composants WebAssembly poussent l'axiome de la porte fermée à son extrême logique. Un composant WASM a **zéro autorité ambiante** : il ne peut pas accéder au système de fichiers, au réseau, à l'horloge, ni même à des nombres aléatoires sauf si une capacité lui est explicitement passée. C'est l'implémentation la plus pure de « le dehors n'existe pas ». Un composant WASM ne sait pas ce qu'est un système de fichiers avant qu'on lui donne un file handle. Il ne sait rien du réseau avant qu'on lui passe une capacité socket. Son univers est exactement l'ensemble des capacités qu'on lui a données. Les systèmes de sécurité à capacités, seL4, Capsicum, WASI, formalisent ce principe : **vous ne pouvez accéder qu'à ce pour quoi vous détenez une capacité (token).** Pas d'autorité ambiante. Pas de permissions implicites. Pas de « c'est sur la même machine, donc il peut probablement le voir ». Si vous n'avez pas la capacité, la ressource n'existe pas pour vous. Le mapping aux espaces est direct : | Concept de capacité | Concept d'espace | |-------------------|---------------| | Token de capacité | Objet monté dans l'espace | | Pas d'autorité ambiante | Axiome de la porte fermée | | Délégation explicite de capacité | Inviter/apporter des objets | | Révocation de capacité | Retirer objets/personnes de l'espace | | Atténuation de capacité | Apporter une vue en lecture seule d'un objet | --- ## Le recadrage : même mécanisme, nouveau but > **Résumé :** Chaque système étudié a construit l'isolation par namespace pour la sécurité. Nous proposons le même mécanisme pour la cognition : aider les personnes à se concentrer en rendant le contexte non pertinent inexistant. Le mécanisme est identique ; le changement de but change tout : l'isolation cognitive optimise les ponts plutôt qu'elle ne les minimise, suppose la collaboration plutôt que l'adversité, et a besoin de mémoire, pourquoi les choses sont là, pas seulement quoi. Voici le mouvement de cette note. Tous les systèmes que nous avons étudiés, Plan 9, namespaces Linux, Docker, Qubes, sandboxes d'agents, origines navigateur, capacités WASM, ont construit l'isolation pour la **sécurité**. La question était toujours : « Comment empêcher du code non fiable d'accéder à des ressources auxquelles il ne devrait pas accéder ? » Nous proposons le même mécanisme pour la **cognition** : « Comment aider une personne, humaine ou agent, à se concentrer sur ce qui compte en rendant tout le reste inexistant ? » Le mécanisme est identique. La table de montage ne se soucie pas de savoir si vous l'utilisez pour empêcher la propagation d'un malware ou pour cadrer un projet d'écriture. La frontière de namespace ne se soucie pas de savoir si elle protège une banque d'un hacker ou un romancier de sa feuille d'impôts. Elle sépare juste l'intérieur de l'extérieur. Mais le changement de but a des conséquences : **L'isolation de sécurité minimise les ponts.** Moins il y a de connexions entre domaines isolés, plus la surface d'attaque est petite. Qubes rend la communication inter-qube délibérément lourde. **L'isolation cognitive optimise les ponts.** Vous devez apporter des objets, inviter des personnes, partager du contexte. L'espace devrait rendre les ponts naturels et intentionnels : faciles quand vous le voulez, impossibles par accident. **L'isolation de sécurité est adversariale.** Supposer le pire. Le code est un malware. L'utilisateur est un attaquant. Le réseau est hostile. **L'isolation cognitive est collaborative.** Supposer la bonne intention. La personne dans l'espace est ici pour travailler. Les objets sont ici parce qu'ils sont pertinents. Les autres personnes sont ici parce qu'elles ont été invitées. **L'isolation de sécurité n'a pas besoin de mémoire.** Un conteneur ne se soucie pas de pourquoi un volume est monté. **L'isolation cognitive a cruellement besoin de mémoire.** Un espace devrait savoir : « Ce document a été apporté le 12 mars parce que Nico a dit qu'il était pertinent pour l'analyse Q2. Sarah a ajouté ces trois fichiers le 15 mars. L'agent a créé ce résumé le 20 mars. » La table de montage n'est pas seulement une liste de ce qui est là ; c'est le récit de l'assemblage de l'espace. ```mermaid graph TD subgraph SEC["Cadrage sécurité (existant)"] S_Q["Qubes OS"] S_D["Docker"] S_B["Sandboxes navigateur"] S_W["WASM/capacités"] S_A["Sandboxes d'agents"] end subgraph COG["Cadrage cognitif (proposé)"] C_S["La primitive espace"] end M["Isolation par namespace\n(vide par défaut,\nmontage explicite,\nporte fermée)"] S_Q --> M S_D --> M S_B --> M S_W --> M S_A --> M M --> C_S C_S --> F1["+ Partage\n(inviter des personnes)"] C_S --> F2["+ Mémoire\n(pourquoi les choses sont là)"] C_S --> F3["+ Identité\n(la personne passe entre espaces)"] C_S --> F4["+ UX des ponts\n(flux naturel entre espaces)"] ``` *Figure : le recadrage. Tous les systèmes existants convergent vers le même mécanisme de namespace. La primitive espace ajoute quatre capacités dont les systèmes motivés par la sécurité n'avaient pas besoin.* Tous les systèmes existants convergent vers le même mécanisme (isolation par namespace). La primitive espace utilise ce mécanisme et ajoute les quatre choses dont les systèmes de sécurité n'avaient pas besoin : partage, mémoire, identité entre espaces et ponts naturels. --- ## La table de montage est le contexte > **Résumé :** La table de montage d'un processus, la liste de ce qui est visible, est structurellement identique à la fenêtre de contexte d'un agent IA. Monter un document dans un espace, c'est ajouter une ligne au contexte. Table de montage plus petite = moins de bruit = meilleure performance. Ce n'est pas une métaphore : c'est la même propriété computationnelle qui rend humains et agents plus efficaces dans des environnements bornés. Voici l'analogie technique qui relie tout. Dans Plan 9 et les namespaces Linux, une **table de montage** décrit la réalité d'un processus : quels systèmes de fichiers sont montés à quels chemins, quels appareils sont visibles, quelles interfaces réseau existent. La table de montage est une spécification complète du namespace : tout ce que le processus peut voir. Pensez maintenant à ce que « contexte » veut dire pour un agent IA. Le contexte, c'est : quels documents sont disponibles, quels outils sont accessibles, qui est dans la conversation, ce qui s'est passé avant. C'est la liste de tout ce que l'agent peut voir et avec quoi il peut interagir. La table de montage EST le contexte. Quand vous « apportez un document dans un espace », vous ajoutez une ligne à la table de montage. Quand vous « invitez une personne », vous montez sa présence. Quand vous « ajoutez un outil », vous montez une capacité. La table de montage de l'espace est son contexte : une description complète, inspectable et modifiable de ce qui existe. Conséquence pratique immédiate pour les agents : **table de montage plus petite = contexte plus petit = meilleure performance.** Un agent opérant dans un espace cadré avec cinq documents pertinents, deux outils et un collaborateur fera mieux que le même agent dans un environnement non borné avec accès à tout. Pas parce qu'il est plus intelligent, mais parce qu'il ne se noie pas dans l'information non pertinente. C'est pourquoi la métaphore de la pièce n'est pas seulement une belle analogie. Les propriétés physiques d'une pièce, bornée, cadrée, meublée explicitement, correspondent directement aux propriétés computationnelles qui rendent humains et agents plus efficaces. | Propriété de pièce | Équivalent table de montage | Effet cognitif | |--------------|----------------------|-----------------| | Murs (frontière) | Isolation par namespace | Concentration : le contexte non pertinent est inexistant | | Meubles (objets) | Volumes/fichiers montés | Pertinence : seul le nécessaire est présent | | Personnes dans la pièce | Identités/présences montées | Collaboration : vous savez qui est là | | Porte (entrée contrôlée) | Délégation de capacité | Confiance : vous choisissez ce qui entre | | But de la pièce | Métadonnées/mémoire de table de montage | Sens : pourquoi ces choses sont ensemble | --- ## Primitives universelles pour personnes universelles > **Résumé :** Si les agents sont des personnes (recherche 009), il n'y a pas d'« infrastructure d'agents » séparée : seulement de l'infrastructure pour personnes. E2B construit des espaces pour un type de personne. Docker construit des espaces pour des processus logiciels. Qubes construit des espaces pour des activités. Aucun n'a la primitive complète. L'espace exige les six propriétés : vide par défaut, porte fermée, montage explicite, partageable, équipé de mémoire, identité entre espaces. C'est ici que la recherche 009 (personhood) change entièrement la lentille. Nico l'a dit directement : « Les primitives construites pour les agents devraient être universelles, fonctionner aussi avec les personnes. Et si nous avons un chapitre avec une définition élargie des personnes, cela change la lentille puisque les agents sont ou seront bientôt techniquement des personnes. » La recherche 009 a établi que la personhood est une catégorie fonctionnelle : identité persistante, capacité de relations, agency, responsabilité. Pas biologie. Si les agents sont des personnes, des personnes fonctionnelles participant à des systèmes avec identité et agency, alors il n'y a pas de catégorie séparée d'« infrastructure d'agents ». Il y a seulement de l'infrastructure. Pour les personnes. E2B ne construit pas des « sandboxes d'agents ». Il construit des espaces pour un type particulier de personne. Docker ne construit pas des « conteneurs d'applications ». Il construit des espaces pour un type particulier de processus logiciel. Qubes ne construit pas des « domaines de sécurité ». Il construit des espaces pour un certain ensemble d'activités. Ils construisent tous la même chose. Aucun n'a construit la chose complète. La primitive espace complète, celle qui fonctionne pour humains, agents et toute entité correspondant au motif personnes, exige tout ce que ces systèmes ont construit plus les quatre extensions identifiées : partage, mémoire, identité entre espaces et ponts naturels. La progression ressemble à ceci : | Système | Vide par défaut | Porte fermée | Montage explicite | Partageable | Mémoire | Identité entre espaces | |--------|:---:|:---:|:---:|:---:|:---:|:---:| | Plan 9 | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | | Linux namespaces | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | | Docker | ✅ | ✅ | ✅ | Partiel¹ | ❌ | ❌ | | Qubes OS | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | | Origines navigateur | ✅ | ✅ | ❌² | ❌ | ❌ | ❌ | | Composants WASM | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | | Sandboxes d'agents | ✅ | ✅ | ✅ | Partiel³ | ❌ | ❌ | | **Primitive espace** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ¹ Docker : les conteneurs partagent des volumes mais pas de présence collaborative humaine. ² Navigateurs : les ressources sont par origine, pas montées explicitement par l'utilisateur. ³ Sandboxes d'agents : certaines supportent volumes/API partagés, pas présence collaborative. Chaque système existant maîtrise les trois premières colonnes : le mécanisme de namespace. Aucun n'a les trois dernières : les fonctionnalités qui transforment un namespace d'outil de sécurité en outil cognitif pour personnes. --- ## Ce que disent les invariants de présentation > **Résumé :** Les espaces fondés sur namespaces satisfont naturellement quatre invariants de présentation que l'informatique actuelle viole : pas de public derrière du privé (n° 1), frontières du contenant dures (n° 4), présence singulière (n° 3), traces là où les actions ont lieu (n° 11). Le modèle de namespace ne se contente pas de soutenir ces invariants : il rend leur violation structurellement impossible. La synthèse Foundations B a identifié douze règles cognitives que les environnements d'information doivent respecter. Les espaces fondés sur namespaces satisfont naturellement plusieurs de celles que l'informatique actuelle viole : **Invariant n° 1 (le public jamais derrière le privé) :** Dans un modèle de namespace, il n'y a pas de « derrière ». Chaque espace est son univers. Vous ne pouvez pas créer accidentellement une ressource publique enfouie dans un espace privé parce que les espaces ne s'imbriquent pas par défaut : ce sont des environnements pairs entre lesquels on se déplace. Si l'imbrication existe, elle suit le modèle de namespace : l'espace intérieur ne peut pas voir l'espace extérieur, donc vous ne pouvez pas exiger par accident un passage par le privé pour atteindre le public. **Invariant n° 4 (le contenant a des frontières) :** Un namespace a la frontière la plus dure possible : le bord de l'existence. Pas une transition floue, pas un contour mou, mais une coupure ontologique nette : dedans est réel, dehors ne l'est pas. Qubes l'a démontré avec les bordures colorées. La primitive espace devrait rendre la frontière aussi perceptible. **Invariant n° 3 (présence singulière) :** Si une personne est « dans » un espace (sa présence est montée dans ce namespace), elle a un lieu. Elle est ici. Si elle part (présence démontée), elle n'est plus ici. Le modèle de namespace donne à la présence un lieu défini et singulier, exactement ce que le modèle « en ligne partout » de Slack échoue à fournir. **Invariant n° 11 (les actions laissent des traces là où elles ont lieu) :** Si la table de montage inclut de la mémoire, si l'espace enregistre pourquoi les choses ont été apportées et ce qui s'est passé dedans, alors les actions laissent des traces au niveau de l'espace. « Nico a ajouté ce fichier le 12 mars » est une trace dans l'espace où cela s'est passé, pas dans un journal d'activité global. --- ## Le pont de compatibilité : monter les apps > **Résumé :** Les apps existantes n'ont pas besoin de comprendre les espaces ; l'espace contrôle ce que l'app peut voir. Plan 9 l'a prouvé ; Docker l'a prouvé à grande échelle. Un modèle d'adoption en trois niveaux (inchangé → conscient du montage → natif de l'espace) permet à l'écosystème d'évoluer graduellement, comme l'adoption des standards web. Question difficile : comment les apps existantes fonctionnent-elles dans des espaces ? On ne peut pas attendre que chaque app devienne « aware » des espaces. Plan 9 a répondu il y a trente ans : **montez-les dedans.** Une app n'a pas besoin de comprendre les espaces. L'espace contrôle ce que l'app peut voir. Lancez un éditeur de texte dans un namespace et il ne peut ouvrir que les fichiers montés dans ce namespace. Lancez un navigateur dans un namespace et il ne peut atteindre que les réseaux montés. L'app fonctionne comme avant ; elle vit seulement dans une réalité cadrée. Docker l'a prouvé à grande échelle : des millions d'applications tournent inchangées dans des conteneurs. Les applications n'ont pas changé. L'environnement a changé. L'application n'en sait rien. Voici le pont de compatibilité pour la primitive espace : - **Niveau 0 (inchangé) :** lancer l'app dans le namespace de l'espace. Elle ne voit que ce qui est monté. Marche immédiatement, sans changement d'app. Limite : l'app ne sait pas qu'elle est dans un espace, ne peut pas participer à la collaboration au niveau espace. - **Niveau 1 (conscient du montage) :** l'app peut lire la table de montage de l'espace pour découvrir quels objets sont disponibles. Elle sait qu'elle est cadrée. Elle peut présenter seulement ce qui est dans l'espace. Exige que l'app comprenne une API de table de montage. - **Niveau 2 (natif de l'espace) :** l'app comprend les espaces comme concept. Elle peut participer au partage, à la présence, à la mémoire. Elle sait qui d'autre est dans l'espace et peut se coordonner avec eux. C'est l'intégration complète, celle qu'on construirait pour de nouvelles apps. La beauté du modèle en niveaux : l'adoption n'exige pas que tout le monde bouge d'un coup. Les apps existantes fonctionnent au niveau 0 sans changement. Avec le temps, les apps qui s'intègrent à l'API d'espace montent de niveau. L'écosystème évolue graduellement, comme les standards web. --- ## L'intuition de commencer vide > **Résumé :** La propriété la plus contre-intuitive des espaces est qu'ils commencent vides. Votre ordinateur commence plein (chaque fichier, chaque app, tout). Une pièce physique commence vide (vous la meublez). Cette inversion, de « filtrer vers le bas » à « construire vers le haut », est le déplacement UX central de l'informatique par namespace. Le cadrage originel de Nico le capture : *« Si je loue un nouveau bureau, ce sera une pièce vide. »* C'est l'inverse de tout système d'exploitation actuel. ```mermaid block-beta columns 2 block:current:1 columns 1 c_label["Actuel : commencer plein"] c_all["📂 Tout visible"] c_filter["🔍 Filtrer et chercher"] c_find["📄 Trouver ce qu'il faut"] c_noise["😵 Le bruit ne disparaît jamais"] end block:spaces:1 columns 1 s_label["Espaces : commencer vide"] s_empty["🚪\nPièce vide"] s_bring["📄 Apporter ce qui compte"] s_focus["🎯 Travailler avec ça seulement"] s_calm["😌 Le bruit n'a jamais existé"] end ``` *Figure : l'inversion. L'informatique actuelle commence avec tout et vous demande de filtrer. Les espaces commencent avec rien et vous demandent de meubler. La différence cognitive est profonde : dans un modèle, le bruit est toujours présent ; dans l'autre, il n'a jamais existé.* --- **Résultats clés :** - L'isolation par namespace, vide par défaut, montage explicite, porte fermée, a été construite et prouvée indépendamment par cinq grandes lignées de systèmes depuis 1992 (Plan 9 → Linux → Docker → Qubes → sandboxes d'agents) - Chaque implémentation existante était motivée par la sécurité ; aucune n'a été conçue pour le cadrage cognitif, alors que le mécanisme est identique - Le passage du cadrage sécurité au cadrage cognitif exige quatre ajouts : partage, mémoire, identité entre espaces et ponts naturels - La table de montage d'un processus est structurellement équivalente au contexte d'un agent IA : table plus petite signifie meilleure performance, mesurablement - Si les agents sont des personnes (recherche 009), les sandboxes d'agents sont déjà de l'infrastructure pour personnes ; elles ne le savent pas encore - Le modèle de compatibilité à trois niveaux (inchangé → conscient du montage → natif de l'espace) permet une adoption graduelle de l'écosystème sans exiger l'adhésion universelle - L'inversion « commencer vide », passer du filtrage d'un monde plein au mobilier d'une pièce vide, est le changement UX central qui rend les espaces cognitivement différents de tout ce qui existe aujourd'hui --- ## Questions ouvertes ### Le problème du couloir > **Résumé :** Si les espaces sont autonomes, la navigation entre eux devient un problème de design sans précédent évident. Si chaque espace est son propre univers, comment retrouve-t-on les choses ? Dans un bâtiment, vous quittez la pièce, marchez dans le couloir, et entrez dans une autre pièce. Quel est le couloir numérique ? Options possibles : - Un espace « home » qui contient des portails (liens) vers vos autres espaces. Comme un hall. - Une recherche qui opère à travers les espaces auxquels vous avez accès, mais cela brise partiellement l'axiome de la porte fermée, parce qu'elle révèle l'existence de choses hors de l'espace courant. - Une mémoire spatiale : vous vous souvenez dans quel espace se trouve quelque chose, comme vous vous souvenez dans quelle pièce vous avez laissé vos clés. ### Le problème de la pièce vide > **Résumé :** Un espace numérique vide a besoin d'affordances par défaut : le mobilier minimal qui le rend utilisable sans le pré-encombrer. Les pièces physiques ont des affordances même vides : murs, sols, interrupteurs, prises. Un espace numérique vide pourrait être paralysant. Quelles sont les affordances par défaut ? Peut-être : un endroit où déposer des objets (drag-in), une manière d'inviter des personnes, une manière de nommer l'espace, une frontière visible. Le mobilier minimum. ### Objets partagés, contextes divergents > **Résumé :** Quand le même objet vit dans plusieurs espaces, les modifications dans l'un peuvent ou non apparaître dans l'autre : la question copie contre référence de 005b, maintenant avec un ancrage technique concret. Si le même document est monté dans deux espaces, et que quelqu'un le modifie dans l'espace A, les modifications apparaissent-elles dans l'espace B ? Dans Docker, un volume partagé reflète immédiatement les écritures dans tous les montages. Mais un espace devrait-il permettre des vues « branchées », le même objet avec des modifications locales non poussées ? C'est la question copie contre référence de la recherche 005b, désormais avec une base technique concrète. ### Profondeur de namespace > **Résumé :** Jusqu'où l'imbrication des espaces devrait-elle aller ? Les bâtiments physiques ont des limites naturelles ; les namespaces n'en ont pas. Des espaces contenant des espaces. Un espace projet qui contient des sous-espaces projet. Jusqu'où l'imbrication devrait-elle aller ? Les bâtiments physiques ont des limites naturelles (des pièces dans un bâtiment, pas des pièces dans des pièces dans des pièces). Le modèle de namespace n'a pas cette limite. L'invariant de présentation n° 12 (la profondeur indique la spécificité) suggère que plus profond devrait vouloir dire plus spécifique, mais combien de niveaux avant que cela devienne impraticable ? ### Le dividende de performance > **Résumé :** Pour les agents, l'isolation par namespace réduit directement le coût en tokens et le temps d'inférence : un bénéfice économique mesurable qui pourrait conduire l'adoption pour des raisons d'efficacité seules. Pour les agents IA, l'isolation par namespace n'est pas seulement cognitive : elle est économique. Moins de contexte signifie moins de tokens, donc inférence plus rapide et coût plus bas. Un projet de 200 documents avec un espace de 5 documents signifie que l'agent traite 5 documents, pas 200. C'est un bénéfice de performance concret et mesurable qui pourrait conduire l'adoption pour des raisons d'efficacité pure, avant même que les bénéfices cognitifs soient prouvés. --- ## Ce que nous avons trouvé > **Résumé :** La primitive espace n'est pas spéculative : c'est une synthèse de trente ans d'isolation par namespace prouvée, complétée par partage, mémoire, identité entre espaces et ponts naturels pour l'usage universel par toutes les personnes, carbone et silicium. La primitive espace, un conteneur persistant, partageable et cadré qui peut contenir n'importe quoi, n'est pas spéculative. Le mécanisme existe. Trente ans d'ingénierie systèmes ont construit, testé et mis à l'échelle l'isolation par namespace : - Plan 9 a prouvé que les namespaces par processus fonctionnent - Linux namespaces a prouvé qu'ils fonctionnent à l'échelle OS - Docker a prouvé qu'ils fonctionnent pour distribuer et lancer des applications partout dans le monde - Qubes a prouvé qu'ils fonctionnent pour des workflows humains quotidiens - Les sandboxes d'agents ont prouvé qu'ils fonctionnent pour des agents IA en production - WASM/capacités ont prouvé que zéro autorité ambiante est viable Ce qu'aucun de ces systèmes n'a fait, c'est construire la primitive complète. Ils ont chacun résolu un cas d'usage : isolation de sécurité pour processus, apps, activités, agents. Ils ont manqué partage, mémoire, identité entre espaces et ponts naturels, les fonctionnalités qui transforment l'isolation d'outil de sécurité en outil cognitif pour personnes. La primitive espace prend le mécanisme prouvé et ajoute les couches manquantes. Ce n'est pas une nouvelle invention. C'est une synthèse : réunir ce qui a été construit en isolation, littéralement, et compléter l'image pour un usage universel. Quand Nico dit « une pièce est vide et on peut y apporter des objets, des personnes et faire des choses », il décrit un namespace Linux avec quatre fonctionnalités dont les conteneurs n'ont jamais eu besoin mais dont les personnes, toutes les personnes, carbone et silicium, ont toujours besoin. --- *Regent's Park · Note 010 · v1.1* *Contexte : 005b — Espaces · 008 — Ontologie des entités · 009 — Personnalité au-delà de la biologie · Fondations B — Invariants de présentation* 🌳