Quelque chose d'intéressant se passe dans l'espace de l'infrastructure agentique, et ce n'est pas ce que la plupart des gens attendaient. Depuis deux ans, le paradigme dominant pour donner aux agents accès à la connaissance a été la Génération Augmentée par Récupération : embarquez vos documents, stockez-les dans une base de données vectorielle, et laissez le modèle les interroger au moment de l'inférence. Le RAG fonctionnait. C'était suffisant. Mais « suffisant » a une date de péremption, et en 2026, cette date est en train d'expirer.
Un nouveau schéma émerge dans l'industrie, et il converge simultanément depuis plusieurs directions. Mintlify a remplacé l'intégralité de son pipeline RAG par un système de fichiers virtuel et a vu la création de session passer de 46 secondes à 100 millisecondes [1]. Turso a construit AgentFS, un système de fichiers basé sur SQLite qui donne à chaque agent son propre bac à sable copy-on-write [2]. Box, le géant du contenu d'entreprise, a annoncé qu'il repositionne l'intégralité de sa plateforme comme une couche de système de fichiers virtuel pour les agents IA [3]. Et ByteDance a publié en open source OpenViking, une base de données de contexte qui organise toute la mémoire, les ressources et les compétences des agents sous forme d'un système de fichiers hiérarchique [4].
Ce ne sont pas des expériences de niche. Ce sont des 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.
Le 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 les passages pertinents au moment de la requête. Les embeddings vectoriels et la recherche par similarité ont résolu ce problème avec élégance.
Mais les agents ne sont pas des chatbots. Un agent ne pose pas une seule question et ne repart pas. Il explore. Il lit un fichier, découvre une référence, la suit, lit un autre fichier, exécute une commande, produit un résultat. Ce n'est pas un problème de récupération. C'est un problème de navigation.
Les pipelines RAG peinent avec cela pour trois raisons. Premièrement, ils sont sans état par conception. Chaque requête est indépendante ; il n'existe pas de concept « j'étais en train 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 est découpé en morceaux anonymes de 512 tokens qui perdent leur contexte organisationnel. Troisièmement, ils sont coûteux à grande échelle. Le calcul des embeddings, la maintenance des index vectoriels et le re-ranking ajoutent tous de la latence et des coûts qui s'accumulent à mesure que le corpus grandit.
Le système de fichiers résout les trois. 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 parce que les opérations sont simples : ls, cat, grep, find. Ce ne sont pas de nouvelles abstractions. Ce sont les interfaces les plus éprouvées de l'informatique.
Ce qui rend ce moment significatif, c'est que le schéma du système de fichiers émerge indépendamment dans des contextes très différents.
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 les docs, les embarquer, les 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 vers la base de données Chroma, les résultats ont été spectaculaires. La création de session est passée de 46 secondes à 100 millisecondes, une amélioration de 460x. Le coût marginal par conversation est passé de 0,0137 $ à pratiquement zéro [1]. L'insight clé : l'agent sait déjà 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.
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 basé sur SQLite avec une sémantique 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 de fichier, appel d'outil et 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 seulement un système de fichiers. C'est un environnement d'exécution auditable et reproductible.
Le VFS enterprise 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 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 magasin de support est ce qui a du sens pour les données. Ce qui rend le positionnement de Box intéressant, c'est la couche de gouvernance : les permissions, les pistes d'audit et les frontières de conformité qui se transmettent automatiquement de la plateforme de contenu à l'agent.
OpenViking de ByteDance pousse le schéma le plus loin. Il organise tout le contexte des agents — mémoires, ressources, compétences, connaissances — sous un protocole viking:// utilisant la sémantique standard des systèmes de fichiers. Les agents naviguent avec ls et find. Mais la partie ingénieuse 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, plonge 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 de complétion des tâches à 52 % [4].
Le schéma qui relie les quatre est ce que j'appellerais la dualité VFS : le système de fichiers gagne comme interface, et la base de données gagne comme substrat. Ce n'est pas un choix binaire. C'est une architecture en couches.
Pourquoi le système de fichiers gagne comme interface est simple. Les LLMs 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 inhabituellement compétents avec ces primitives parce qu'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 le rencontrez là où vivent ses données d'entraînement.
Pourquoi la base de données gagne comme substrat est tout aussi clair. Dès que la mémoire d'un agent doit être partagée, auditée, interrogée par plusieurs agents, ou rendue fiable sous 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 une voie vers la souffrance.
Le schéma 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 comme des 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 comme des chemins viking://. Box utilise sa plateforme de contenu enterprise mais l'expose comme un arbre 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 le fournit. Pourquoi ajouter une couche d'abstraction ?
Je voulais répondre à cette question empiriquement, alors j'ai construit markdownfs, un système de fichiers virtuel from-scratch en Rust conçu spécifiquement pour les charges de travail agentiques [6]. Il supporte l'ensemble complet des commandes de type UNIX (ls, cat, grep, find, chmod, chown), le versionnage de style Git avec stockage adressable par contenu, les permissions multi-utilisateurs, et expose trois méthodes d'accès : un 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 magasin de blobs adressable par contenu utilisant le hachage SHA-256, avec tokio::RwLock pour un accès concurrent sûr. Les fichiers sont dédupliqués automatiquement. Le contrôle de version utilise le même modèle commit/revert que Git, mais au niveau du système de fichiers. La persistance est gérée via des snapshots bincode atomiques.
Quand j'ai comparé markdownfs au 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 était en moyenne environ 130x plus rapide dans l'ensemble. Les raisons sont structurelles, pas accidentelles. Les opérations en mémoire éliminent entièrement les E/S disque. Le stockage adressable par contenu signifie que les fichiers dupliqués ne sont stockés qu'une seule fois. Les lectures zero-copy signifient que l'agent obtient les données sans surcharge de sérialisation. Et parce que l'intégralité de l'état du système de fichiers vit dans un seul processus, il n'y a pas de frontières d'appels système à franchir.
La comparaison est particulièrement frappante pour les opérations que les agents effectuent le plus fréquemment :
| Opération | Pourquoi le VFS Gagne |
|---|---|
| Lectures répétées (l'agent relit le contexte) | En mémoire, zero-copy. Pas de recherches disque, pas de défauts de cache de pages. |
| grep sur des fichiers (l'agent cherche des patterns) | Tout le contenu est en mémoire. Pas de traversée de répertoires, pas de gestion de descripteurs de fichiers. |
| Création rapide de fichiers (l'agent produit des artefacts de travail) | Pas de journalisation du système de fichiers, pas d'allocation d'inodes sur disque, pas de fsync. |
| Listage de répertoires (l'agent explore la structure) | Recherche BTreeMap vs appels système readdir. |
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 versionnage intégré (vous avez besoin de 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 surtout, 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 l'écosystème converge.
Le 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 : versionnage, 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 genuinement pas ce qu'il cherche. Mais l'évaluation honnête est que le RAG a été sur-appliqué. Beaucoup des cas d'usage où les équipes ont déployé des pipelines RAG — récupération de documentation, navigation dans les bases de code, gestion des connaissances d'entreprise — sont mieux servis par une interface de système de fichiers.
Les preuves sont frappantes. L'accélération de 460x 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, 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 bases de données vectorielles du tout [5].
L'avenir est probablement hybride. RAG pour la recherche sémantique ouverte. Système de fichiers pour la navigation structurée et l'exécution de tâches. Mais le centre de gravité se déplace vers le système de fichiers, et les implications stratégiques sont significatives.
Si vous construisez de l'infrastructure agentique, vous avez besoin d'une stratégie VFS. Voici pourquoi.
Pour 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 feront partie du flux de travail agentique. Celles qui ne le font pas deviendront invisibles aux agents, ce qui signifie invisibles aux utilisateurs.
Pour 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 réalité 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.
Pour les entreprises : c'est l'histoire de la gouvernance qui compte. Le discours de Box ne porte pas vraiment sur les systèmes de fichiers. Il porte sur le fait que leur modèle de permissions, leur piste d'audit et leur infrastructure de conformité s'étendent automatiquement aux agents lorsque le contenu est accédé via la couche VFS [3]. C'est la réponse à la question que chaque RSSI pose : « Comment permettons-nous aux agents d'accéder à notre contenu sans créer un cauchemar de sécurité ? »
La pile d'infrastructure agentique a évolué en 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 interface unique et familière.
C'est là le vrai insight. 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.
Les entreprises qui comprennent cela — Mintlify, Turso, Box, ByteDance — ne construisent pas quelque chose de nouveau. Elles reconnaissent quelque chose d'ancien et lui donnent un nouveau rôle.
Références :
[1] Mintlify. (2026, 2 avril). How we built a virtual filesystem for our Assistant. Mintlify Blog.
[2] Turso. (2026). The Missing Abstraction for AI Agents: The Agent Filesystem. Turso Blog.
[4] Volcengine. (2026). OpenViking: An open-source context database for AI Agents. GitHub.
", "source_hash": "sha256:ea80be6a7f1e92f4b1cd368f4ce0178d49cbe7579c9693b08d174d40c5961953", "model": "claude-sonnet-4-6", "generated_at": "2026-04-13T19:26:44.440321+00:00" }