Comment j'ai construit mon système — une introduction

Quand on travaille tous les jours avec un assistant IA, on se rend vite compte de deux choses. La première : on peut produire beaucoup plus, beaucoup plus vite. La seconde : on perd le focus.

Sans structure, l'IA vous fait diverger. Une question en amène trois, trois en amènent dix, et à la fin de la journée vous avez exploré beaucoup de choses sans avoir vraiment décidé ce qui comptait. La productivité brute n'est pas la productivité réelle.

J'ai donc construit un système — pas pour automatiser plus, mais pour garder le contrôle. Voici comment il s'organise.

Deux couches, deux lecteurs

La distinction de fond est simple :

• Une couche pour la machine — bases de données, fichiers de connaissance, registres. Granulaire, indexable, écrite pour être lue par un modèle de langage.
• Une couche pour l'humain — le journal de fin de journée. Synthétique, narrative, écrite pour être relue par moi.

Cette séparation n'est pas cosmétique. Elle traite directement le problème que l'IA crée : trop d'output, pas assez de synthèse. La machine a son flux, j'ai le mien. Ils ne se mélangent pas.

L'espace de travail

Tous les projets vivent dans un seul dossier au même niveau, comme des livres sur une étagère. Pas de regroupement par client ni par thème — la hiérarchie complique le déplacement et la recherche, et elle vieillit mal.

Chaque projet a un nom court en PascalCase (Investments, PrometeoBookkeeping, BusinessDevelopment). Le contexte — pour qui, à propos de quoi — n'est pas dans le nom. Il est stocké à part, sous forme d'étiquettes. Cela permet de renommer ou de réorganiser sans tout casser.

Deux dossiers spéciaux fixes : _Meta/ — le hub, qui contient tous les registres et la base de connaissances ; et OLD/ — l'équivalent d'une corbeille, où je garde par sécurité ce dont je n'ai plus besoin pour le moment, sans le supprimer.

Les projets sont enregistrés, pas juste nommés

Quand un nouveau projet démarre, il reçoit une fiche dans trois fichiers CSV centraux :

• projects.csv — la liste maîtresse. Une ligne par projet : identifiant, nom, statut, dépôt GitHub, description.
• project-tags.csv — la connexion entre projets et étiquettes (une ligne par relation).
• tags.csv — le dictionnaire des étiquettes.

Pourquoi des CSV plutôt qu'une vraie base de données ? Parce que les CSV se lisent dans n'importe quel éditeur, se versionnent dans Git, se diffusent sans serveur, et — surtout — un modèle de langage les comprend nativement. Pas de driver, pas de SQL, pas de schéma à maintenir. Le compromis : l'intégrité référentielle est une question de discipline, pas d'application. Pour un système personnel, c'est largement suffisant.

Comment chaque session démarre

Au début d'une session, l'assistant lit le dossier dans lequel je l'ai ouvert et applique une logique simple :

• À l'intérieur d'un projet → il lit le rules.md du projet (son brief), regarde ses étiquettes, et charge automatiquement les fichiers de connaissance correspondants.
• À la racine de l'espace de travail → il propose de créer un nouveau projet.
• Hors de l'espace de travail → il avertit que ce n'est pas la convention.

Le but : être prêt à travailler dès le premier échange, sans avoir besoin de raconter le contexte à chaque fois.

La base de connaissances

Dans le dossier _Meta-Knowledge/, il y a un fichier Markdown par étiquette. Le nom du fichier correspond exactement à l'étiquette. Quand un projet est ouvert, ses étiquettes déclenchent le chargement automatique des fichiers correspondants.

Cela rend la connaissance transversale aux projets. Une décision prise pendant une tâche d'écriture sur un sujet est disponible quand je travaille sur n'importe quel autre projet partageant la même étiquette — automatiquement, sans réimporter quoi que ce soit.

Les fichiers grossissent avec le temps. Quand une section dépasse environ 50 lignes, elle est extraite dans un sous-fichier dédié et le parent devient un index. Ce mécanisme évite l'effet « fichier qui devient illisible ».

Le journal — la couche humaine

À la fin d'une journée de travail, je signale « fin de journée » et l'assistant lit les journaux de session de tous les projets touchés ce jour-là, puis les synthétise dans une seule entrée à _Meta-Journal/YYYY-MM-DD.md.

Ce n'est pas un journal technique. C'est un récit. Ce qui a été décidé, ce qui mérite d'être retenu, ce que je veux relire dans six mois pour me souvenir de comment on est arrivé là.

C'est cette couche-là qui empêche le système de me submerger. Sans elle, je serais en réaction permanente à l'output de l'IA. Avec elle, je peux fermer la journée en sachant ce qui a compté.

Comment les sessions se ferment

À la fin d'une session de travail :

• Journal de session — chaque projet garde un session-log.md. Une entrée brève : date, 4–6 puces sur les décisions et les prochaines étapes. Pas un log fichier-par-fichier (l'historique Git est là pour ça) — plutôt « voici pourquoi on a fait ce qu'on a fait ». Seules les 10 dernières sessions sont conservées.
• Mise à jour des connaissances — si quelque chose de durable a été appris pendant la session, le fichier de connaissance correspondant est mis à jour avant la fermeture.

Pourquoi cela marche

Le système n'est pas particulièrement complexe. Ce qui le rend efficace, ce sont quelques principes :

• Une seule source de vérité par chose. Pas de doublons, pas de « où est la version la plus récente ».
• Tout est versionné dans Git. L'historique des décisions est récupérable.
• La machine et l'humain ont chacun leur couche. Elles ne se contaminent pas.
• Le contexte est chargé automatiquement. Je ne réexplique jamais.

Chaque pièce existe parce qu'elle a résolu une friction réelle. Aucune pièce n'a été ajoutée par anticipation. C'est probablement ce qui le rend tenable dans le temps.