Un fichier, des directives, et Claude fait le reste — comment j'ai structuré 500 mails sans effort

Dans l'article précédent, j'ai décrit un système de contextes structurés pour travailler avec un LLM sur des sujets complexes. Des dossiers, des fichiers de mission, des manifestes de chargement, des notes atomiques reliées entre elles. Le modèle est puissant. Mais il n'est pas simple à comprendre, et encore moins à mettre en place quand on part de zéro.

Et surtout — je ne suis pas arrivé là du premier coup. Ce système est le résultat de 40 jours d'essais, d'erreurs, de versions jetées et reconstruites. Personne n'achète une Ferrari comme première voiture. C'est pareil ici : il faut d'abord rouler, comprendre comment ça fonctionne, et seulement ensuite monter en complexité.

Cet article raconte comment j'ai commencé. Pas avec un framework. Avec un fichier.

Le problème : 500 mails et zéro vision d'ensemble

En tant que membre du conseil syndical de ma copropriété, je reçois de très nombreux mails. Du syndic, de propriétaires, de locataires. Parfois un nouveau sujet, parfois la nième réponse à un thread qui dure depuis des mois.

Le volume n'est pas le vrai problème. Le vrai problème, c'est que chaque personne qui répond à un thread a le contexte dans la tête — c'est elle qui a suivi le sujet depuis le début. Moi, quand j'ouvre un nouveau mail, je dois remonter toute la chaîne, retrouver qui a dit quoi, comprendre où on en est. Pour un chantier qui dure six mois, c'est un travail considérable. Multipliez par quinze sujets en parallèle, et vous comprenez pourquoi j'ai cherché une autre solution.

J'ai décidé de confier à Claude la structuration de cette information entrante. Il récupère les mails automatiquement, les associe à leur thread, et agrège tout. La récupération automatique des mails est de la pure technique — je n'en parlerai pas ici. Ce qui m'intéresse, c'est ce qui se passe après : comment j'ai construit, étape par étape, un système de mémoire qui tient la route.

Étape 1 — Un fichier, une phrase

Au départ, c'était un simple fichier context.md avec une directive vague :

« Agrège les informations et découpe en thématiques. »

Et ça marchait. Claude recevait les mails, les classait par sujet, maintenait un résumé par thématique. Pour un premier essai, c'était déjà utile.

Étape 2 — Le problème de la perte d'information

Puis j'ai vu que je perdais de l'information. Quand un chantier était fini, par exemple, Claude mettait à jour l'agrégation : « chantier terminé, réception conforme ». Très bien. Mais l'historique disparaissait. Quand est-ce que le chantier avait débuté ? Quand a-t-il été retardé ? Quand un avenant a-t-il été signé ? Tout ça était écrasé par la dernière mise à jour.

Il me fallait les deux : l'information finale et l'historique.

La solution a été de demander à Claude de maintenir, en plus de l'agrégation, un log chronologique. Si un chantier débute, c'est une ligne. S'il est retardé, c'est une autre ligne. Si un avenant concerne le chantier, c'est encore une autre ligne. Dans l'agrégation, on voit l'état courant : « chantier commencé en janvier, terminé en juin, conforme ». Dans le log, on voit chaque étape, chaque événement, dans l'ordre.

Deux vues du même sujet. L'une pour comprendre vite, l'autre pour remonter le fil.

Étape 3 — Les directives métier

Puis j'ai voulu donner des règles de traitement plus fines. Pas des règles génériques — des directives spécifiques à mon contexte.

Par exemple : quand une personne est citée par son nom de famille, trouver le prénom correspondant. Ça paraît trivial, sauf quand deux prestataires portent le même nom de famille. Dans ce cas, la directive précise : utiliser le sens de l'email pour désambiguïser.

Autre cas : certaines personnes sont appelées tantôt par leur nom de jeune fille, tantôt par leur nom marital. Sans directive, Claude crée deux entrées différentes pour la même personne. Avec la directive, il sait que c'est la même.

Autre exemple encore : séparer les petits débiteurs (moins de 100 euros) des gros débiteurs. Pas la même gestion, pas le même suivi, pas le même niveau d'attention.

Ces directives ne sont pas des règles universelles. Elles sont spécifiques à mon contexte. Et c'est précisément ce qui les rend puissantes : elles encodent une connaissance que moi seul possède, et que Claude applique ensuite systématiquement, sans oublier, sans se fatiguer.

Étape 4 — Le mur des 1 000 lignes

Ça fonctionnait bien. Mon context.md organisait correctement ma connaissance. Mais il commençait à gonfler. 500 lignes, puis 800, puis plus de 1 000.

Le problème n'est pas seulement la lisibilité pour moi. C'est la fenêtre de contexte du LLM. Plus le fichier est gros, plus Claude doit tout charger à chaque session. Et comme je l'ai expliqué dans l'article précédent, un LLM perd en précision sur les informations enfouies au milieu d'un long document. Mon fichier unique commençait à jouer contre moi.

Étape 5 — Séparer les directives du contexte

Première solution : extraire les directives dans un fichier séparé.

Les directives — comment traiter les noms, comment séparer les débiteurs, comment gérer les doublons — ce ne sont pas des informations sur la copropriété. Ce sont des règles de traitement. Les mélanger avec le contexte, c'est mélanger la recette avec les ingrédients.

Un fichier directives.md d'un côté. Le context.md de l'autre. Déjà mieux.

Mais context.md continuait à gonfler.

Étape 6 — Découper le contexte par thématique

La vraie solution a été de demander à Claude de découper mon context.md en autant de fichiers qu'il y avait de thématiques. Les travaux dans un fichier. Les finances dans un autre. Les prestataires dans un troisième. Et ainsi de suite.

Et pour qu'il s'y retrouve : un readme.md qui liste tous les fichiers, avec une description courte de chaque thématique.

Le premier découpage ne m'a pas entièrement convaincu. C'est normal : je lui avais demandé de découper sans lui donner de directives précises sur comment le faire, donc il a fait comme il l'entendait. Et parfois, sa vision du découpage ne correspondait pas à la mienne. J'avais un fichier de plusieurs milliers de lignes — je ne le voyais pas forcément de la même manière que lui.

Avec un peu de discussion, et quelques directives renforcées sur le découpage, on est arrivé à quelque chose qui me convenait. Les fichiers sont correctement découpés. Et surtout : Claude ne lit et n'écrit désormais que dans les fichiers dont il a besoin. Plus de fichier monolithique chargé en entier à chaque session. La fenêtre de contexte ne s'emballe plus.

Étape 7 — Externaliser le vocabulaire

Dernier raffinement : nous avons beaucoup de vocabulaire technique dans le contexte de la copropriété. Des noms techniques, des acronymes (DPAE…), des termes juridiques. Plutôt que de les laisser éparpillés dans chaque fichier thématique, je lui ai demandé de tout centraliser dans un glossary.md.

Le modèle final — simple et robuste

Et voilà. Sans aller vers un système de mémoire complexe — pas de manifeste de chargement, pas de notes atomiques, pas de mémoire épisodique — j'ai un modèle qui couvre largement mon besoin :

directives.md       — règles de traitement
glossary.md         — vocabulaire technique
readme.md           — index des thématiques
themes/
  residence.md
  travaux.md
  finances.md
  prestataires.md
  ...               — un fichier par thématique

Quatre concepts. Un fichier de règles, un glossaire, un index, et des fichiers thématiques. C'est tout.

Pour donner une idée concrète, voici le readme.md réel de mon contexte copropriété, tel qu'il existe aujourd'hui — 15 fichiers thématiques :

Ce répertoire était auparavant un seul fichier monolithique de plus de 1 000 lignes. Il a été décomposé en 14 fichiers thématiques en une seule session, puis debiteurs.md a été extrait de acteurs.md le même jour — parce que la gestion des débiteurs méritait son propre espace.

Ce que ça change au quotidien

Le gain est massif.

Pour une personne qui suit un sujet depuis six mois — le syndic qui gère un chantier, le prestataire qui répond sur un devis — le contexte est dans sa tête. Elle sait où on en est parce que c'est elle qui a vécu chaque étape.

Moi, quand j'arrive sur un mail, je n'ai pas ce luxe. Je dois remonter la chaîne, relire les échanges précédents, reconstituer l'état du sujet. Avec 15 sujets en parallèle et des threads qui s'étalent sur des mois, c'est un travail énorme.

Avec le système en place, tout est agrégé. Je sais qu'il y a un nouveau mail. Mais surtout, je sais quelles sont les évolutions, comment a évolué une donnée, où on en est. J'ai la piste historique. J'ai la liste des personnes contactées. J'ai la liste des prestataires avec leurs domaines et leurs montants. Toutes ces informations sont organisées et stables. La liste des prestataires ne change pas à chaque mail — elle s'enrichit progressivement.

Et quand je me pose une question — « quel prestataire a fait le dernier devis pour les gouttières ? », « où en est le dossier avec tel débiteur ? » — il suffit de la poser à Claude. Si vous avez 300, 400, 500 mails et que vous devez retrouver la réponse à ce genre de question en fouillant votre boîte de réception, c'est l'enfer.

Par où commencer ?

Si vous voulez essayer, je conseillerais de passer par Claude CoWork quand on ne vient pas du développement. C'est plus simple, on n'a pas besoin de sortir tout un outil de développement. Juste deux choses à faire :

1. Créer un fichier context.md
2. Donner 2-3 directives dans la conversation : « je vais te donner des informations, tu les agrèges, tu historises s'il y a plusieurs étapes pour cette information, et tu mets tout ça dans le context.md »

Et puis vous commencez à discuter avec Claude. Vous lui donnez de l'information, vous voyez comment il l'organise, vous ajustez. Le but de la première fois, c'est juste d'apprendre. Pas de construire le système parfait. Apprendre comment ça fonctionne, comment l'IA réagit, ce qu'elle fait bien et ce qu'elle fait mal.

Pour ma part, je suis passé directement à Claude Code parce que je viens du développement. C'était plus simple pour moi, c'est plus puissant. Mais le choix de l'outil n'est pas le plus important — ce qui compte, c'est la méthode.

Le coût d'entrée

Combien de temps ça m'a pris ? En partant de zéro, sans jamais connaître Claude, j'en suis à 40 jours environ pour arriver au système actuel (plus une tonne d'autres trucs dont il faudra parler : veille concurrentielle, ce blog est aussi entièrement géré par Claude, gestion de la documentation support, agent data analyst…). Mais j'ai un avantage : avant d'être product manager, j'ai été développeur. Ça aide pour la partie outillage. Pour la partie méthode — comment structurer l'information, quelles directives donner — c'est accessible à n'importe qui.

La question de la confiance

Bien sûr que Claude fait des erreurs. Mais un humain en fait aussi.

Ce qu'il faut voir, c'est qu'on ne confierait évidemment pas la gestion de documents bancaires à une IA. Il y a des domaines où on n'a pas le droit à l'erreur. Mais pour structurer des mails de copropriété, si de temps en temps Claude rejoint mal une information, ce n'est pas très grave. Le gain de temps est tellement important que quelques approximations sont un prix acceptable.

Et surtout, j'ai toujours une porte de sortie : ma boîte mail. Tous les mails bruts sont conservés dans le repository — une copie de tous les emails bruts dans le projet Claude. Je peux à tout moment faire une recherche directement sur les mails originaux via Claude Code, sans passer par l'information agrégée. Le système structuré est un accélérateur, pas un remplacement. La source de vérité reste accessible.

Du personnel au professionnel

J'ai appliqué exactement la même démarche pour mon travail de PM. Au départ, c'était vraiment du bricolage — un fichier contexte, un skill, des discussions dans la console sans trop savoir comment ça fonctionnait. Et puis j'ai appris. Je me suis lancé, j'ai fait plein d'erreurs.

J'ai jeté la première version de ce que j'avais fait. La deuxième, je pensais la jeter aussi en me disant « ça sera bien meilleur, mais au moins je vais apprendre des choses ». Et puis la deuxième, je l'ai gardée — elle fonctionne encore. Et j'ai itéré dessus pour arriver à une troisième version, celle que je décris dans l'article précédent.

Faites évoluer, ne sautez pas d'étapes

J'en suis à la troisième version de mon système. Je viens de convertir les derniers éléments de la V2 vers la V3. Et peut-être qu'un jour, j'aurai une V4, encore plus complexe, mais qui apporte encore plus de valeur.

Mais il faut être pragmatique. On fait une évolution de version parce que les besoins sont croissants — pas juste parce que ça fait plaisir. Sinon, c'est du surengineering.

Le chemin, c'est : un fichier → des directives → un découpage → un glossaire → un système. Chaque étape répond à un problème concret. On ne passe à la suivante que quand la précédente ne suffit plus. Et à chaque étape, on a quelque chose qui fonctionne.

Commencez par un fichier. Vous verrez bien quand il faudra le découper.