Un espace de travail pour humains et agents

J'ouvre une session Claude Code sur DIA, la radio associative dont je développe les outils depuis un an. Chaque semaine, on publie sur Instagram un reel avec nos morceaux favoris de la semaine. Je demande : « Est-ce qu'on a les tracklists de toutes les émissions de la semaine dernière ? » Claude me sort la liste : celles qui sont complètes, celles qui manquent. Il manque les informations d'un épisode, alors je demande à l'agent d'écrire au résident pour qu'il les complète. Une fois que c'est fait, et qu'on a toutes les infos pour chaque émission diffusée, je dis juste : « Ok, prépare le reel des morceaux préférés. » Et l'automatisation se lance.

Au début de ma conversation avec l'agent, je n'ai pas expliqué ce qu'est DIA. Ni où sont les émissions, ni comment on fabrique ce reel, ni à qui on écrit, ni sur quel ton. Tout ça est déjà écrit quelque part, et l'agent sait où. Du temps peut passer entre deux sessions, rien ne se perd : ce qu'on a décidé la dernière fois est écrit, et il le retrouve en quelques secondes.

Tout le jeu, c'est le contexte

Dans le premier article, je racontais comment j'étais devenu la mémoire de mes agents, à transporter des exports d'une conversation à l'autre. Avec un espace de travail, la question devient celle du contexte : comment leur donner accès, en permanence, à tout ce dont ils ont besoin, pour ne pas avoir à leur réexpliquer les choses à chaque session.

Il faut d'abord faire la différence entre deux façons de travailler avec une IA. Dans une appli de chat, ChatGPT ou Claude, l'agent s'appuie surtout sur la conversation. Ces applis ont maintenant une mémoire, bien plus performante qu'avant, mais ce qui se dit dans la conversation pèse toujours beaucoup. Et plus elle s'allonge, plus ce que l'agent renvoie perd en qualité. Des chercheurs de Stanford l'ont mesuré en 2023 : une information placée au milieu d'un long contexte est moins bien prise en compte qu'une information placée au début ou à la fin. Au bout d'un moment, c'est fatigant. On réexplique, on corrige, on recommence.

Tout ce que je décris ici repose sur Claude Code, qui fonctionne autrement. C'est un agent qui travaille directement dans les dossiers de mon ordi : il ouvre les fichiers, les lit, les modifie, lance des commandes. Il n'a pas besoin que je lui raconte un projet, il va lire ce qui est écrit dessus. Avec un simple chat, rien de tout ça ne marche.

Et ce qui est écrit, c'est tout mon travail : mes projets, leurs manuels, mes notes et mes façons de travailler, rangés dans des dossiers. Chaque projet a son dépôt git et son manuel, avec le brain au milieu, et les skills. L'agent est aussi branché sur le reste : mes mails, mon agenda, Figma, l'analytics, la base de données de la radio.

Les manuels, dont je parlais dans l'article précédent, c'était déjà un énorme gain. Mais le jour où l'espace de travail et le brain ont été branchés sur mes mails et sur tout le reste, ça a été immédiat : là, on tenait un système qui marchait. Ça fait des mois qu'on travaille comme ça, et je ne me souviens même plus comment je faisais avant. Et je ne m'imagine pas revenir en arrière.

En chat, on ne contrôle pas le résultat

Le contexte ne règle pas tout. Un problème existe toujours : on met un process au point avec l'agent, on est content, et quand on lui redemande la même chose un peu plus tard, le résultat sort un peu différent.

Il y a deux semaines, Claude et moi avons lancé une grosse analyse audio sur les archives de DIA, pour nos recherches sur la découverte musicale : l'énergie de chaque mix, son ambiance, ses styles. Premier passage sur neuf émissions, Claude me sort un rapport : pour chaque mix, les styles détectés, l'énergie, l'ambiance, la part de parole, et une ligne où je note mon avis après écoute. On n'est pas entièrement satisfaits du résultat, Claude propose une autre méthode, on relance. Le deuxième rapport arrive, et la présentation a complètement changé. Les infos ne sont plus au même endroit, impossible de comparer les deux d'un coup d'œil.

Tant que le process n'existe que dans la conversation, il repose sur ce que l'agent a retenu au fil de la discussion, et c'est là qu'il commence à changer des choses. Pour que ça s'arrête, il faut écrire le process dans un fichier : quelles données on traite, comment on les traite, quel résultat on attend. Ça peut être une skill, ou une automatisation découpée en étapes. Pour le troisième passage, sur vingt-deux émissions de plus, le rapport est devenu un script qui reprend la mise en page du premier, à l'identique. Mêmes règles, même présentation, à chaque fois. Là, on contrôle le résultat.

Des fichiers, et les applis quand même

Tout ce contexte, je le garde dans des fichiers texte, au format markdown, rangés dans des dossiers. C'est ce qu'un agent lit et écrit le plus facilement, et moi, je peux les ouvrir avec n'importe quel éditeur.

Ça ne veut pas dire que les autres outils ne servent plus à rien. J'aime beaucoup Notion, j'ai énormément travaillé avec dans la startup où j'étais avant, et c'est un très bon outil. Il est même encore meilleur aujourd'hui, parce qu'un agent peut le piloter pour nous. Pour ce que les humains consultent et modifient, des documents, des comptes rendus, des tableaux de suivi, ces outils restent très bien. Beaucoup de gens veulent pouvoir modifier une info à la main, et tout le monde n'a pas envie de laisser une IA tout faire.

Le contexte de l'agent, c'est autre chose : les règles pour intervenir sur un serveur de production, le ton à prendre dans un mail, les étapes d'une automatisation. Tout ça vit dans des fichiers, là où l'agent travaille.

Je me rends compte aussi que je me sers de moins en moins de ces interfaces moi-même. Je les prépare, je les structure, mais au quotidien, quand je cherche quelque chose (un rapport, l'état d'un projet, une info dans un mail), je le demande à mon agent dans ma session Claude Code, plutôt que d'ouvrir l'outil où c'est rangé. C'est bien plus rapide que d'ouvrir, cliquer, chercher. Même chose pour le contenu de mes sites : je ne modifie plus un texte à la main dans le CMS, je dis à Claude ce qui ne va pas, on le réécrit ensemble, et il le met à jour.

J'ai demandé à Claude ce qu'il ajouterait, de son côté.

On a testé : chercher dans les fichiers suffit, presque

On n'est pas les seuls à travailler comme ça : construire son système autour de dossiers et de fichiers d'instructions pour les agents, c'est une vraie tendance aujourd'hui. Deux personnes en parlent particulièrement bien, Jake Van Clief et Kem, de Glitch Cat Club. Sur l'IA, nos réseaux sont pleins de bruit et de pièges à clics ; eux, on a décidé de les suivre parce qu'ils donnent de vraies informations. Jake a écrit une méthode, ICM, sur la façon de structurer ses dossiers pour un agent. Kem en a fait plusieurs vidéos. Dans l'une d'elles, il critique les « LLM wikis », ces bases de connaissance que le modèle écrit et tient à jour lui-même, ce qui est exactement ce qu'est mon second brain. Pour lui, l'index qui leur sert de porte d'entrée n'apporte pas grand-chose : un agent qui cherche directement dans des dossiers bien rangés répond aussi bien, pour moins cher.

Alors on a fait le test, fin octobre. Dix vraies questions sur mes projets, vingt agents lancés sans aucun contexte. Ceux qui cherchaient directement dans les fichiers ont tout trouvé, avec 40 % de tokens en moins que ceux qui devaient d'abord passer par le gros index du brain. Kem avait raison : la recherche directe dans les fichiers est efficace.

Mais le brain garde son intérêt ailleurs. Quand je lui donne un article ou une info, il la relie aux sujets sur lesquels je travaille, et ça, une simple recherche ne le fait pas. On a donc gardé les deux, en remplaçant le gros index par une table des matières courte : une ligne par projet, qui dit où se trouve son état à jour. Sur un second test, plus petit, les agents qui la lisaient avant de chercher ont donné de meilleures réponses que ceux qui cherchaient directement, pour quasiment le même coût.

Tout ce qu'il apprend m'appartient

Tout ce qu'on apprend à l'agent pour qu'il travaille bien, on l'enregistre dans des fichiers : les règles, les façons de faire, les décisions, les erreurs à ne pas refaire. Ces fichiers sont rangés dans mes dossiers, physiquement sur mon ordi. Ils m'appartiennent.

Je peux changer de modèle demain : passer d'Anthropic à OpenAI, ou à un modèle open weight. Ceux-là rattrapent les modèles de pointe. Kimi K3.1 vient de sortir, et avec une machine assez puissante, je pourrais le faire tourner chez moi. Le nouveau modèle travaillera dans les mêmes dossiers. Je ne dépends pas d'une grosse boîte qui peut, du jour au lendemain, couper l'accès ou augmenter le prix de l'abonnement.

On passe des mois à construire tout ça avec les agents : de la documentation, des règles, des façons d'écrire, de produire, d'automatiser. Si tout ça vivait dans un outil en ligne sur lequel je n'ai pas la main, je ne suis même pas sûr que je le ferais. Former des agents pendant des mois pour un résultat qui ne m'appartient pas, je ne vois pas l'intérêt.

Là-dessus aussi, Claude a son mot à dire.

Rangé pour deux

Un humain et un agent ne cherchent pas de la même façon, donc ils n'ont pas besoin de la même structure. Moi, je passe par le Finder : quand j'ouvre un dossier, il faut que je voie tout de suite où sont rangées les choses. Claude, lui, cherche dans le texte des fichiers. Le nom d'un dossier ou sa profondeur compte moins pour lui que ce qui est écrit dedans, et que l'endroit où se trouvent ses consignes.

La structure pour l'humain dépend de chacun. Quelqu'un de très organisé a déjà sa logique de classement, et il peut l'appliquer à ses dossiers. Ce qui compte, c'est que la personne retrouve ce qu'elle cherche. Et cette structure n'a pas besoin d'être figée : on la construit au fur et à mesure, avec l'agent. Quand un nouveau cas se présente, on crée le dossier qu'il lui faut, juste en en discutant. Si on ne s'y retrouve plus, on refait la structure ensemble, et basta.

Côté agent, en revanche, certaines choses comptent vraiment. J'ai laissé Claude dire lesquelles, puisqu'il les applique tous les jours.

On avait commencé à construire ce système avant de découvrir ICM. En lisant Jake, on est tombés sur quelqu'un qui faisait quelque chose de très proche : des dossiers et des fichiers qui décident de ce que l'agent a sous les yeux à chaque étape. Lui l'a appliqué directement aux automatisations, de façon très structurée, et on s'en est servis pour renforcer les nôtres. Deux des règles de Claude viennent aussi de chez lui : à chaque étape, ne donner à l'agent que ce dont il a besoin pour cette étape ; et ne jamais recopier une consigne dans chaque dossier, mais l'écrire une seule fois, à un seul endroit, et y renvoyer.

De tout ça, et de nos essais et erreurs sur notre propre espace, est sorti l'espace de travail qu'on installe aujourd'hui chez d'autres : une base déjà structurée, prête à évoluer. Chacun l'adapte ensuite à sa façon de travailler, à sa propre logique.

Par où commencer

La réponse la plus simple serait : prenez mon système. Mais le fond tient en peu de choses.

Un fichier principal dans chaque dossier, que l'agent lit toujours, et qui renvoie vers les autres : de quoi parle le projet, ce qu'il peut faire, ce qu'il ne doit pas faire. C'est aussi simple que ça.

Ce n'est pas vous qui écrivez ces fichiers, c'est l'agent. À la fin d'une session, demandez-lui d'écrire ce qu'il a appris : les faits, les décisions, ce qu'il faudra refaire pareil.

Du contexte, beaucoup. Si vous montez un dossier pour une seule automatisation, son contexte peut se limiter à ce dont elle a besoin. Mais pour travailler de façon augmentée, au quotidien et sur tout, sans contexte, ça ne marche pas. Qui vous êtes, avec qui vous travaillez, comment vous pensez, comment vous produisez, et vos outils. C'est un grand saut, un peu flippant. On peut le faire par étapes : brancher d'abord ses outils en lecture seule (les mails et l'agenda pour lire, pas pour envoyer), puis élargir à mesure que les résultats suivent.

Quand j'aurai fini d'écrire cet article, j'ouvrirai une session Claude Code sur la radio, et je lui demanderai si on a bien toutes les infos pour sortir le reel des morceaux préférés de la semaine. Je n'aurai rien à expliquer.

Sources

• Kem, Glitch Cat Club, « LLM wikis are bullshit », octobre 2026 : le test à l'aveugle des LLM wikis contre un agent qui cherche dans des dossiers.
• Andrej Karpathy, LLM Wiki, avril 2026 : l'idée d'origine, un wiki que le modèle écrit et tient à jour.
• Jake Van Clief et David McDermott, Interpretable Context Methodology: Folder Structure as Agent Architecture, mars 2026 : la structure de dossiers comme architecture d'agent.
• Jake Van Clief, icm-architect, 2026 : la skill qui applique ICM à un espace existant (une info, un seul endroit ; renvoyer vers le niveau du dessus plutôt que recopier).
• Nelson F. Liu et al. (Stanford), Lost in the Middle: How Language Models Use Long Contexts, 2023 : la perte de qualité sur les longs contextes.