Quelque chose d'intéressant se passe dans l'univers de l'infrastructure agentique, et ce n'est pas ce que la plupart des gens attendaient. Ces deux dernières années, le paradigme dominant pour donner aux agents l'accès aux connaissances a été la Retrieval-Augmented Generation (RAG) : intégrer vos documents, les stocker dans une base de données vectorielle, et laisser le modèle les interroger au moment de l'inférence. Le RAG a fonctionné. C'était suffisamment bon. Mais « suffisamment bon » a une durée de conservation, et en 2026, cette durée expire.
\nUn nouveau motif émerge dans toute l'industrie, convergeant depuis plusieurs directions à la fois. Mintlify a remplacé l'intégralité de son pipeline RAG par un système de fichiers virtuel et a vu la création de sessions passer de 46 secondes à 100 millisecondes [1]. Turso a construit AgentFS, un système de fichiers reposant sur SQLite qui offre à chaque agent son propre bac à sable avec sémantique de copie à l'écriture (copy-on-write) [2]. Box, le géant du contenu d'entreprise, a annoncé qu'il repositionnait l'intégralité de sa plateforme comme une couche de système de fichiers virtuel pour les agents d'IA [3]. Et ByteDance a open-sourcé OpenViking, une base de données de contexte qui organise toute la mémoire, les ressources et les compétences des agents sous la forme d'un système de fichiers hiérarchique [4].
\nCe ne sont pas des expériences de niche. Ce sont les signaux d'un changement fondamental. Le système de fichiers devient l'interface universelle pour la cognition des agents, et la base de données devient discrètement son substrat.
\nLe RAG était la bonne réponse pour 2023. Vous aviez un tas de documents, un modèle avec une fenêtre de contexte limitée, et vous aviez besoin d'un moyen de faire remonter des extraits pertinents au moment de la requête. Les embeddings vectoriels et la recherche par similarité ont résolu ce problème avec élégance.
\nMais les agents ne sont pas des chatbots. Un agent ne pose pas une question et ne s'en va pas. Il explore. Il lit un fichier, découvre une référence, la suit, lit un autre fichier, exécute une commande, écrit un résultat. Ce n'est pas un problème de récupération. C'est un problème de navigation.
\nLes pipelines RAG peinent à gérer cela pour trois raisons. Premièrement, ils sont sans état par conception. Chaque requête est indépendante ; il n'existe pas de concept du type « je venais de regarder ce répertoire, montre-moi maintenant le fichier adjacent ». Deuxièmement, ils aplatissent la structure. Un site de documentation avec une hiérarchie claire de sections, de pages et d'exemples de code se retrouve déchiqueté en fragments anonymes de 512 tokens qui perdent leur contexte organisationnel. Troisièmement, ils sont coûteux à grande échelle. Le calcul des embeddings, la maintenance de l'index vectoriel et le reclassement ajoutent tous de la latence et des coûts qui s'accumulent à mesure que le corpus croît.
\nLe système de fichiers résout ces trois problèmes. Il est intrinsèquement avec état (l'agent a un répertoire de travail). Il préserve la structure (répertoires, sous-répertoires, fichiers). Et il est rapide car les opérations sont simples : ls, cat, grep, find. Ce ne sont pas des abstractions nouvelles. C'est l'interface la plus éprouvée de l'informatique.
Ce qui rend ce moment significatif, c'est que le motif du système de fichiers émerge indépendamment dans des contextes très différents.
\nLe ChromaFs de Mintlify est peut-être l'exemple le plus instructif. Mintlify alimente des assistants de documentation pour des milliers d'entreprises. Leur architecture originale était du RAG classique : découper la documentation, l'intégrer, récupérer au moment de la requête. Quand ils l'ont remplacée par ChromaFs, un système de fichiers virtuel qui intercepte les commandes UNIX et les traduit en requêtes de base de données Chroma, les résultats ont été spectaculaires. La création de sessions est passée de 46 secondes à 100 millisecondes, une amélioration de 460 fois. Le coût marginal par conversation est tombé de 0,0137 $ à pratiquement zéro [1]. L'idée clé : l'agent sait déjà comment naviguer dans un système de fichiers. Lui apprendre à utiliser cat /auth/oauth.mdx est trivial comparé à lui apprendre à formuler la bonne requête vectorielle.
L'AgentFS de Turso s'attaque à un problème différent : l'isolation et l'auditabilité des agents. Chaque agent obtient son propre système de fichiers reposant sur SQLite avec une sémantique de copie à l'écriture (copy-on-write). Le système de fichiers hôte est une couche de base en lecture seule ; l'agent écrit dans une couche delta SQLite. Chaque opération sur les fichiers, chaque appel d'outil et chaque changement d'état est enregistré. L'intégralité du runtime de l'agent, fichiers, état, historique, tient dans un seul fichier SQLite portable [2]. Ce n'est pas juste un système de fichiers. C'est un environnement d'exécution vérifiable et reproductible.
\nLe VFS entreprise de Box est le plus stratégiquement significatif. Le PDG de Box, Aaron Levie, a été explicite : les agents ont besoin d'un système de fichiers pour effectuer du travail de connaissance en entreprise [3]. Mais Box ne propose pas un système de fichiers au sens littéral. Ils proposent un « contrat de livraison de données dynamique » qui peut être soutenu par du stockage objet, des bases de données relationnelles, ou leur propre plateforme de contenu. Le système de fichiers est l'interface ; le stockage sous-jacent est ce qui a du sens pour les données. Ce qui rend la stratégie de Box intéressante, c'est la couche de gouvernance : les permissions, les pistes d'audit et les limites de conformité qui se transmettent automatiquement de la plateforme de contenu à l'agent.
\nL'OpenViking de ByteDance pousse le motif le plus loin. Il organise tout le contexte, les mémoires, les ressources, les compétences et les connaissances des agents sous un protocole viking:// en utilisant la sémantique standard des systèmes de fichiers. Les agents naviguent avec ls et find. Mais la partie intelligente est le modèle d'accès par niveaux : chaque élément de contexte est traité en trois couches. L0 est un résumé en une phrase pour une récupération rapide. L1 est une vue d'ensemble avec les informations essentielles pour la planification. L2 est le contenu complet pour une lecture approfondie [4]. L'agent commence par L0, creuse dans L1 quand il a besoin de plus, et ne charge L2 que lorsqu'il effectue un travail détaillé. Sur le benchmark LoCoMo, cela a réduit la consommation de tokens de 24,6 millions à 4,2 millions tout en augmentant les taux d'achèvement des tâches à 52 % [4].
Le motif qui relie ces quatre approches est ce que j'appellerais la dualité VFS : le système de fichiers l'emporte comme interface, et la base de données l'emporte comme substrat. Ce n'est pas un choix de type « l'un ou l'autre ». C'est une architecture en couches.
\nLa raison pour laquelle le système de fichiers l'emporte comme interface est simple. Les LLM sont entraînés sur Internet, et Internet est construit par des développeurs qui pensent en termes de fichiers, de répertoires, de chemins et d'outils en ligne de commande. Les modèles sont particulièrement compétents avec ces primitives car ils ont vu des milliards d'exemples de développeurs naviguant dans des bases de code, lisant des fichiers et exécutant des commandes shell. Quand vous donnez un système de fichiers à un agent, vous allez à sa rencontre là où résident ses données d'entraînement.
\nLa raison pour laquelle la base de données l'emporte comme substrat est tout aussi claire. Dès que la mémoire d'un agent doit être partagée, auditée, interrogée par plusieurs agents, ou rendue fiable en situation de concurrence, vous avez besoin des garanties d'une base de données. Les transactions ACID, le contrôle d'accès, la recherche sémantique, l'historique des versions : ce sont des problèmes difficiles que les bases de données ont passé des décennies à résoudre. Les réimplémenter au-dessus d'un système de fichiers littéral est un chemin vers la douleur.
\nLe motif VFS vous donne les deux. L'agent voit des fichiers et des répertoires. Le système voit des tables, des index et des listes de contrôle d'accès. ChromaFs stocke tout dans Chroma mais l'expose sous forme de fichiers. AgentFS stocke tout dans SQLite mais l'expose comme un système de fichiers POSIX. OpenViking utilise son propre moteur de stockage mais l'expose sous forme de chemins viking://. Box utilise sa plateforme de contenu d'entreprise mais l'expose comme une arborescence navigable.
L'objection naturelle à tout cela est : pourquoi ne pas simplement utiliser le vrai système de fichiers ? POSIX est là. Chaque système d'exploitation l'embarque. Pourquoi ajouter une couche d'abstraction ?
\nJe voulais répondre à cette question de manière empirique, alors j'ai construit markdownfs, un système de fichiers virtuel écrit from-scratch en Rust conçu spécifiquement pour les charges de travail des agents [6]. Il prend en charge l'ensemble complet des commandes de type UNIX (ls, cat, grep, find, chmod, chown), un versionnement de style Git avec stockage adressable par contenu, une gestion des permissions multi-utilisateur, et expose trois méthodes d'accès : une CLI/REPL, une API HTTP/REST, et un serveur MCP auquel des agents comme Claude et Cursor peuvent se connecter directement.
L'architecture est simple : une table d'inodes en mémoire soutenue par un stockage d'objets adressables par contenu utilisant le hachage SHA-256, avec tokio::RwLock pour un accès concurrent sécurisé. Les fichiers sont dédupliqués automatiquement. Le contrôle de version utilise le même modèle de commit/revert que Git, mais au niveau du système de fichiers. La persistance est gérée par des instantanés atomiques en bincode.
Quand j'ai benchmarké markdownfs contre le système de fichiers natif sur les opérations standard des agents (création de fichiers, lectures, écritures, listage de répertoires, grep, find, déplacement, copie, suppression), markdownfs a été en moyenne environ 130 fois plus rapide sur toute la ligne. Les raisons sont structurelles, pas accidentelles. Les opérations en mémoire éliminent entièrement les entrées/sorties disque. Le stockage adressable par contenu signifie que les fichiers en double ne sont stockés qu'une seule fois. Les lectures sans copie (zero-copy) signifient que l'agent obtient les données sans surcharge de sérialisation. Et parce que l'état entier du système de fichiers vit dans un seul processus, il n'y a pas de frontières d'appels système à franchir.
\nLa comparaison est particulièrement frappante pour les opérations que les agents effectuent le plus fréquemment :
\n| Opération | \nPourquoi le VFS l'emporte | \n
|---|---|
| Lectures répétées (l'agent relit le contexte) | \nEn mémoire, sans copie. Pas de recherches sur disque, pas de défauts de cache de pages. | \n
| grep sur plusieurs fichiers (l'agent recherche des motifs) | \nTout le contenu est en mémoire. Pas de parcours de répertoires, pas de gestion de descripteurs de fichiers. | \n
| Création rapide de fichiers (l'agent produit des artefacts de travail) | \nPas de journalisation du système de fichiers, pas d'allocation d'inodes sur disque, pas de fsync. | \n
| Listage de répertoires (l'agent explore la structure) | \nRecherche dans une BTreeMap contre des appels système readdir. | \n
Mais la performance n'est pas le vrai argument. Le vrai argument est ce que le système de fichiers natif ne peut pas faire. Un système de fichiers POSIX n'a pas de concept de recherche sémantique. Il n'a pas de versionnement intégré (il vous faut Git pour ça). Il n'a pas de modèle d'accès par niveaux (vous obtenez le fichier entier ou rien). Il n'a pas de déduplication de contenu. Il n'a pas de piste d'audit des opérations des agents. Et de manière critique, il n'a pas d'interface MCP, ce qui signifie que les agents ne peuvent pas y accéder via le protocole standard vers lequel converge l'écosystème.
\nLe VFS n'est pas seulement plus rapide. C'est une primitive plus riche. Il vous donne l'interface familière de ls et cat tout en ajoutant les capacités dont les agents ont réellement besoin : versionnement, permissions, recherche, déduplication et accès natif au protocole via MCP ou HTTP.
Pour être clair, le RAG n'est pas mort. La recherche vectorielle reste précieuse pour les requêtes floues et sémantiques où l'agent ne sait vraiment pas ce qu'il cherche. Mais l'évaluation honnête est que le RAG a été surutilisé. Bon nombre des cas d'usage où les équipes ont déployé des pipelines RAG, récupération de documentation, navigation dans des bases de code, gestion des connaissances d'entreprise, sont mieux servis par une interface de système de fichiers.
\nLes preuves sont frappantes. L'accélération de 460 fois de Mintlify est venue du remplacement du RAG par un système de fichiers, pas de son augmentation [1]. Des recherches de Letta montrent que les agents utilisant de simples opérations de système de fichiers atteignent 74 % de précision sur les benchmarks de mémoire, ce qui est compétitif avec les outils de récupération spécialisés. Et les approches de recherche par mots-clés agentiques peuvent atteindre plus de 90 % des performances du RAG sans aucune base de données vectorielle [5].
\nL'avenir sera probablement hybride. Le RAG pour la recherche sémantique ouverte. Le système de fichiers pour la navigation structurée et l'exécution des tâches. Mais le centre de gravité se déplace vers le système de fichiers, et les implications stratégiques sont significatives.
\nSi vous construisez de l'infrastructure agentique, vous avez besoin d'une stratégie VFS. Voici pourquoi.
\nPour les entreprises SaaS : la leçon de Box est que le système de fichiers devient la surface d'intégration pour les agents. Si le contenu de votre plateforme n'est pas navigable comme un système de fichiers, les agents vous contourneront. Les entreprises SaaS qui exposent leurs données via des interfaces de type système de fichiers deviendront partie intégrante du flux de travail agentique. Celles qui ne le feront pas deviendront invisibles pour les agents, ce qui signifie invisibles pour les utilisateurs.
\nPour les fournisseurs d'infrastructure : la base de données ne disparaît pas. Elle se déplace sous le système de fichiers. C'est en fait une bonne nouvelle pour les entreprises de bases de données. Turso l'a compris et a construit AgentFS au-dessus de SQLite. Chaque agent qui démarre crée une nouvelle base de données. Plus le monde fait tourner d'agents, plus le monde a besoin de bases de données. Mais la base de données doit disparaître derrière une abstraction de système de fichiers.
\nPour les entreprises : c'est l'aspect gouvernance qui compte. Le pitch de Box ne concerne pas vraiment les systèmes de fichiers. Il s'agit du fait que leur modèle de permissions, leur piste d'audit et leur infrastructure de conformité s'étendent automatiquement aux agents quand le contenu est accédé via la couche VFS [3]. C'est la réponse à la question que chaque RSSI pose : « Comment laisser les agents accéder à notre contenu sans créer un cauchemar sécuritaire ? »
\nLa pile d'infrastructure agentique a évolué par phases claires : outils (MCP), compétences et graphes de contexte. Le système de fichiers virtuel s'inscrit dans cet arc comme le mécanisme de livraison pour les trois. Les outils MCP sont invoqués via le système de fichiers. Les compétences sont stockées comme des fichiers. Les graphes de contexte sont navigués comme des arborescences de répertoires. Le système de fichiers ne remplace pas ces couches. Il les unifie derrière une seule interface familière.
\nC'est la vraie idée. Le système de fichiers n'est pas une nouvelle idée. C'est l'abstraction la plus ancienne de l'informatique. Mais c'est exactement pourquoi il fonctionne pour les agents. Dans un monde où nous inventons de nouveaux paradigmes chaque trimestre, le mouvement le plus puissant pourrait être de revenir à l'interface la plus éprouvée que nous ayons et de mettre une base de données moderne derrière elle.
\nLes entreprises qui comprennent cela, Mintlify, Turso, Box, ByteDance, ne construisent pas quelque chose de nouveau. Elles reconnaissent quelque chose de vieux et lui donnent un nouvel emploi.
\nRéférences :
\n[1] Mintlify. (2026, April 2). How we built a virtual filesystem for our Assistant. Mintlify Blog.
\n[2] Turso. (2026). The Missing Abstraction for AI Agents: The Agent Filesystem. Turso Blog.
\n\n[4] Volcengine. (2026). OpenViking: An open-source context database for AI Agents. GitHub.
\n\n", "source_hash": "sha256:b576661fe0d14759bc1b074608bc4208873bd898abf89987b9d7e9a126ba21b9", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-08-07T07:21:31.143347+00:00" }