Pourquoi les systèmes de fichiers reviennent au centre de l’attention

 (madalitso.me)
36 points par GN⁺ 2026-03-09 | 1 commentaires | Partager sur WhatsApp
  • Dans le récent écosystème des agents IA, les systèmes de fichiers reviennent au premier plan et s’imposent comme un moyen de gérer un contexte persistant distinct des bases de données
  • La fenêtre de contexte des LLM ressemble davantage à un tableau blanc qui s’efface qu’à une mémoire durable, et le système de fichiers constitue le moyen de stockage persistant le plus simple pour résoudre ce problème
  • Claude Code, Cursor et d’autres implémentent une mémoire à long terme via un stockage du contexte fondé sur des fichiers ; des fichiers comme CLAUDE.md et aboutme.md servent à contenir l’identité de l’agent et les informations sur son environnement
  • La gestion du contexte basée sur le système de fichiers devient un sujet central, et de grands acteurs comme LlamaIndex, LangChain, Oracle et Archil publient successivement articles et produits sur le sujet
  • Alors que prolifèrent les fichiers de contexte d’agent comme CLAUDE.md, AGENTS.md et .cursorrules, le format Agent Skills (SKILL.md) d’Anthropic a été adopté par Microsoft, OpenAI, GitHub et Cursor, gagnant ainsi en interopérabilité
  • Selon une étude de l’ETH Zürich, les fichiers de contexte peuvent au contraire réduire le taux de réussite des tâches et augmenter de plus de 20 % le coût d’inférence ; il faut donc n’y décrire que les exigences minimales
  • Les fichiers ne dépendent pas d’une application particulière et s’imposent, à l’ère des agents IA, comme une interface ouverte permettant le passage d’un outil à l’autre, la combinaison de workflows et le maintien de la continuité

Everyone is talking about files : tout le monde parle des fichiers

La fenêtre de contexte n’est pas une mémoire

  • La mémoire humaine comprend le stockage à long terme, le rappel sélectif et l’oubli des informations inutiles, tandis que la fenêtre de contexte des LLM ressemble à un tableau blanc continuellement effacé
  • Lorsqu’on utilise Claude Code, à mesure que l’alerte "context left until auto-compact" approche, le contexte accumulé par l’agent — base de code, préférences, décisions prises, etc. — est compressé ou perdu
  • Le système de fichiers résout cela de la manière la plus simple : on écrit l’historique dans des fichiers, puis on les relit quand nécessaire
    • CLAUDE.md fournit un contexte persistant sur le projet
    • Cursor enregistre les anciens historiques de chat sous forme de fichiers consultables
    • Le fichier aboutme.md joue le rôle de descripteur d’identité portable contenant préférences, compétences et style de travail, transportable d’une application à l’autre sans orchestration par API

Étude de l’ETH Zürich : le paradoxe des fichiers de contexte

  • Un article récent de l’ETH Zürich évalue si les fichiers de contexte au niveau du dépôt aident réellement les agents de programmation à accomplir leurs tâches
  • Les résultats sont contre-intuitifs : sur plusieurs agents et modèles, les fichiers de contexte réduisent au contraire le taux de réussite des tâches, tandis que le coût d’inférence augmente de plus de 20 %
    • Les agents recevant des fichiers de contexte explorent plus largement, exécutent davantage de tests et parcourent plus de fichiers, mais mettent plus de temps à atteindre le code qui doit réellement être modifié
    • Le fichier agit comme une checklist que l’agent suit trop scrupuleusement
  • La conclusion de l’article n’est pas « n’utilisez pas de fichiers de contexte », mais plutôt que les exigences inutiles rendent les tâches plus difficiles et que les fichiers de contexte ne doivent décrire que le strict minimum
  • Le problème ne vient pas de la couche persistante du système de fichiers elle-même, mais de l’habitude consistant à rédiger CLAUDE.md comme un document d’onboarding de 2 000 mots
Publicité

Le format de fichier devient l’API — mais quel fichier ?

  • Aujourd’hui coexistent CLAUDE.md, AGENTS.md, copilot-instructions.md et .cursorrules ; s’il existe un consensus sur le fait que les agents ont besoin d’un contexte persistant fondé sur le système de fichiers, le nom des fichiers et le format de leur contenu ne font pas encore l’objet d’un accord
  • Dans son article sur le système de fichiers social, Dan Abramov propose un principe de conception central : l’AT Protocol traite les données utilisateur comme des fichiers dans un dépôt personnel, et les applications évitent les collisions via des espaces de noms fondés sur des noms de domaine, sans avoir à s’accorder sur ce qu’est exactement un « post »
    • La base de données de chaque application devient une donnée dérivée, c’est-à-dire une vue matérialisée en cache de tous les dossiers utilisateurs
  • Anthropic a présenté Agent Skills comme standard ouvert : le format SKILL.md a été adopté par Microsoft, OpenAI, Atlassian, GitHub et Cursor
    • Une skill écrite pour Claude Code fonctionne aussi dans Codex et Copilot — le format de fichier devient l’API
  • NanoClaw est un framework léger d’assistant IA personnel qui adopte un modèle de « skills plutôt que fonctionnalités »
    • Si l’on veut le support de Telegram, au lieu d’un module Telegram, une skill /add-telegram (un fichier Markdown) apprend à Claude Code comment l’intégrer
    • Parce qu’elles sont des fichiers, les skills sont portables, auditables et combinables — nul besoin de serveur MCP ni de marketplace de plugins
  • C’est cela, l’interopérabilité sans coordination : si deux applications peuvent lire du Markdown, elles peuvent partager du contexte ; si elles comprennent le format SKILL.md, elles peuvent partager des fonctionnalités ; sans contrat de partenariat ni réunion d’un organisme de normalisation, c’est le format de fichier lui-même qui joue le rôle de coordination

Déplacement du goulot d’étranglement

  • L’architecture de données traditionnelle a été conçue sur l’hypothèse que le stockage était le goulot d’étranglement, mais à mesure que la capacité de traitement a dépassé les E/S de stockage, le paradigme a basculé vers la séparation du stockage et du calcul (S3 + clusters de calcul temporaires)
  • Un phénomène similaire apparaît avec les agents IA : le goulot d’étranglement n’est plus la performance du modèle ni le calcul, mais le contexte
    • Les modèles sont suffisamment intelligents, mais oublient
    • Le système de fichiers est la manière la plus efficace de gérer un contexte persistant exactement là où l’agent s’exécute — sur la machine du développeur, dans l’environnement et au plus près des données déjà présentes
    Publicité

Le système de fichiers est déjà un graphe

  • Sur Twitter, certains ont fait remarquer que dire « il n’y a pas besoin de graphe pour les agents si l’on utilise un système de fichiers » revient en réalité à nier qu’on utilise déjà un graphe
    • Un système de fichiers est une structure en arbre composée de répertoires, sous-répertoires et fichiers, autrement dit un graphe orienté acyclique (DAG)
    • Quand un agent utilise ls, grep, lit des fichiers ou suit des références, il parcourt déjà un graphe
  • Dans l’article d’Oracle, Richmond formule la distinction la plus nette : le système de fichiers gagne comme interface, la base de données gagne comme couche sous-jacente
    • Dès qu’il faut gérer l’accès concurrent, la recherche sémantique à grande échelle, la déduplication ou la pondération par fraîcheur, on finit par construire son propre index, ce qui revient en pratique à une base de données
  • L’interface fichier est puissante parce qu’elle est universelle et déjà comprise par les LLM, tandis que la couche sous-jacente basée sur une base de données est puissante parce qu’elle fournit les garanties nécessaires à l’exploitation réelle
  • L’avenir n’est pas fichiers contre bases de données, mais une architecture où le fichier est l’interface d’interaction pour les humains et les agents, avec en dessous une couche adaptée au cas d’usage

Une redéfinition de l’informatique personnelle

  • Le système de fichiers pourrait redéfinir le sens même de l’informatique personnelle à l’ère de l’IA
    • Données, contexte, préférences, skills et mémoire existeraient dans des formats possédés par l’utilisateur, lisibles par n’importe quel agent et non enfermés dans une application particulière
    • aboutme.md fonctionne dans OpenClaw/NanoClaw aujourd’hui, et dans de nouveaux outils demain
    • Les fichiers de skills sont portables, et le contexte de projet se maintient au-delà des outils
  • C’est une vision proche de ce que l’informatique personnelle visait à l’origine, avant que tout ne migre vers des applications SaaS fermées et des bases de données propriétaires
    • Les fichiers sont le protocole ouvert originel, et à mesure que les agents IA deviennent l’interface principale de l’informatique, ils forment une couche d’interopérabilité permettant, sans demander la permission à quiconque, de changer d’outil, de combiner des workflows et de préserver la continuité entre applications
    Publicité
  • Cette vision garde toutefois une part d’idéalisme : l’histoire des formats ouverts est pleine de standards victorieux sur le papier mais inefficaces dans la pratique
    • Les entreprises ont tout intérêt à rendre leurs fichiers de contexte légèrement différents pour maintenir un coût de changement élevé
    • Le fait même que CLAUDE.md, AGENTS.md et .cursorrules coexistent au lieu de converger vers un format universel montre que la fragmentation est l’état par défaut
    • L’étude de l’ETH Zürich rappelle que même lorsqu’un format existe, il est difficile d’écrire un bon fichier de contexte, et qu’un mauvais fichier peut être pire que pas de fichier du tout
  • Le message central de Dan Abramov :

    Nos souvenirs, nos pensées et nos designs doivent survivre plus longtemps que le logiciel qui les a produits

    • Ce n’est pas seulement un argument technique, mais une question de valeurs ; si le système de fichiers convient à ce rôle, ce n’est pas parce que c’est la meilleure technologie, mais parce que c’est la seule technologie qui appartient déjà à l’utilisateur

À lire aussi

1 commentaires

 
GN⁺ 2026-03-09
Avis sur Hacker News

  • Les fichiers constituent une forme fondamentale de liberté qui permet aux utilisateurs de posséder directement leurs données
    Cela rend possible la souveraineté sur la confidentialité, l’intégrité et la disponibilité
    En tant qu’axe central de la liberté numérique, cela devrait être considéré au même titre que les licences FOSS

    • Grâce aux capacités de raisonnement des LLM, on n’a plus vraiment à se soucier de la structure des fichiers
      Le langage naturel existe directement dans le fichier, et la lisibilité devient la spécification
      Toute personne capable d’écrire de façon lisible peut écrire dans un fichier, et l’exécuter immédiatement comme dans un REPL
    • C’est pourquoi les tentatives de grandes entreprises tech comme Apple pour faire disparaître la notion de fichier sont gênantes
      Elles enferment les données dans les apps, qui ne peuvent plus exister indépendamment, et rendent aussi l’import/export difficile
      Je travaille sur un outil qui extrait les données des sauvegardes en fichiers granulaires pour les transférer dans une bibliothèque numérique personnelle
      Les données immuables peuvent simplement être archivées, mais le plus grand défi est de rendre à nouveau les données modifiables « vivantes », éditables dans des apps
    • Je pense que les fichiers de configuration sont bien meilleurs qu’un stockage centralisé comme le Windows Registry
      Ils sont faciles à modifier temporairement et à partager, et le sens des paramètres y est clairement défini
      Je n’aime pas la façon dont Windows traite les fichiers comme des citoyens de troisième zone

  • Je pense la même chose du point de vue du SaaS
    Plus le code est éphémère et spécifique à un domaine, plus les données (les fichiers) doivent être standardisées et d’une stabilité presque ennuyeuse
    Un format lisible uniquement par une app donnée est une dette technique qui finit par faire échouer le projet
    Si l’on peut encore ouvrir un fichier JPEG de 1995, c’est parce qu’il ne dépend pas d’un logiciel particulier

    • Mon système de gestion de photos, qui a plus de 10 ans, utilise le système de fichiers et EXIF comme source de vérité
      C’est une approche correcte, éprouvée à plusieurs reprises
      Les couches d’abstraction comme Google Photos ou Immich ne sont là que pour la commodité ; le cœur, ce sont les fichiers
      Au travail aussi, je gère la recherche et la documentation avec des fichiers markdown et csv
      lien vers le projet elodie
    • Le problème de la gestion photo aujourd’hui, c’est que les modifications, tags et informations d’album sont tous stockés comme métadonnées externes
      Quand on change de plateforme, tout l’historique des retouches disparaît
      La fonction d’annulation est pratique, mais j’aimerais que ces changements soient standardisés pour être portables

  • Je veux mentionner Plan 9 de Bell Labs
    Plan 9 from Bell Labs

    • Je construis un orchestrateur d’agents appelé agenc
      J’ai demandé à Claude des travaux antérieurs pertinents, et il a proposé Plan 9 ; c’est exactement le type de concept dont nous avons besoin aujourd’hui
      La philosophie de minimisation des privilèges des agents est la même que celle du modèle de sécurité en entreprise
      Plan 9 est simplement arrivé trop tôt
    • Parmi les nouveaux systèmes de fichiers, GeFS mérite d’être examiné

  • Cela rappelle une fois de plus que Plan 9 et UNIX avaient raison
    L’interface la plus puissante, ce sont les fichiers texte au-dessus d’un système de fichiers
    Il est temps de recréer 9p2026
    Cela dit, certains concepts de base de l’article sont faux — un système de fichiers n’est pas un arbre mais un graphe pouvant contenir des cycles

    • Je me demande quelles sont les fonctionnalités clés de Plan 9, si on peut les brancher avec FUSE, ou s’il faut une magie plus profonde

  • C’est aussi un sujet qui résonne profondément chez moi
    Au cours de l’année écoulée, j’ai déplacé mes données personnelles depuis une dizaine de SaaS vers une structure de répertoires unique
    Un système de fichiers organisé suffit pour un utilisateur seul et élimine la fragmentation des données
    À l’avenir, je pense qu’on verra émerger de nouvelles bases de données capables de prendre en charge des écritures multi-utilisateurs sûres sans rendre le système de fichiers opaque
    Cela me rappelle un peu le rôle de QMD pour la recherche

  • Nous sommes encore à un stade immature de l’usage de l’IA
    Les systèmes de production fonctionneront sur des structures de données cohérentes et extensibles, mais les agents qui les construiront utiliseront des technologies fondées sur le système de fichiers
    L’interface utilisateur va probablement évoluer au-delà du desktop vers des interfaces vocales et visuelles
    Par exemple, lors d’un appel vidéo, on peut lire les expressions du visage et l’intonation pour obtenir davantage de contexte

    • Dans une démo IA récente, le système extrait du contexte à partir de la voix et des gestes, le convertit en texte, puis l’envoie au LLM
      Ce n’est pas du multimodal complet, mais c’était très intéressant
    • Malgré tout, la saisie de texte ne disparaîtra sans doute pas
      Écrire aide à structurer la pensée, et ce n’est pas aussi spontané que la parole
      Même si la reconnaissance vocale (STT) devient excellente, l’intelligence humaine continuera de fonctionner autour de l’écriture

  • Les fichiers ne sont utiles que si on peut les retrouver
    Autrement dit, la recherche et l’indexation sont indispensables, mais elles commencent à se casser à grande échelle
    La question clé devient donc : quelle est la taille de la base de connaissances qu’un agent peut manipuler ?
    J’ai analysé ce sujet à partir des premiers principes dans l’article « a good agentic KB »

  • Dans un ensemble de fichiers bien organisés, comme une base de code, les agents de code trouvent bien l’information
    Mais avec des données désordonnées, la structuration via un système de fichiers est bien plus difficile
    C’est plus complexe qu’une recherche sémantique dans une vector DB
    Les bases de code conservent naturellement une structure en graphe grâce au principe DRY, mais les données non liées au code ne fonctionnent pas ainsi
    Donc oui, je suis d’accord pour dire que le système de fichiers constitue une bonne structure de contexte à long terme, mais il ne remplace pas encore complètement la recherche

  • Je pense que le système de fichiers est une abstraction médiocre
    Le fait de devoir accrocher des fichiers à une structure consciente d’arborescence de répertoires est inefficace
    Le modèle relationnel ou une structure fondée sur des identifiants uniques me semble meilleur

    • L’avantage du système de fichiers, c’est la préservation de la localité des changements
      Les changements dans une branche n’affectent pas les autres
      À l’inverse, dans une base de données, un UPDATE ou un DELETE peut avoir des effets globaux, ce qui est risqué
      C’est pourquoi un modèle hybride, avec une structure en arbre surmontée d’index de base de données comme dans les OS modernes, est idéal
    • NTFS utilise en interne la base de données MFT
      Les noms de fichiers sont indexés en b+tree, et les données de fichier sont également stockées dans la MFT
      Un répertoire n’est finalement qu’une ligne avec l’attribut « directory=true »
      Une approche pleinement relationnelle comme WinFS a échoué pour des raisons de performance, et Skydrive a pris sa place
    • Dans la plupart des systèmes de fichiers, les fichiers sont identifiés de manière unique par un inode, et peuvent être référencés par plusieurs liens
      On semble souvent l’oublier
    • Les UUID sont opaques pour les humains, mais pour les agents ce sont des identifiants parfaitement distincts
      Au final, on ira sans doute vers un stockage de blobs de style S3 avec un bon index au-dessus, et des répertoires générés à la demande comme des tags
      Il ne restera alors que des fonctions de regroupement du type « les documents liés au T3 sont dans ce répertoire »