J'ai un second brain

Dans Un an avec des agents, je racontais une année de travail avec eux. Un point y revient en permanence : un agent ne se souvient de rien. Chaque conversation est la première.

La première réponse, incomplète, a été le manuel dans chaque repo. Un fichier qui explique au projet ce qu'il est, comment il est construit, ce qu'on n'y touche pas. L'agent ouvre une session en sachant déjà tout ça.

Ça règle le contexte technique d'un projet. Ça ne règle rien d'autre.

Tout ce qui n'est pas du code n'avait toujours nulle part où vivre. Les idées. Les articles gardés pour plus tard. Les décisions prises avec un client et leurs raisons. Ce qu'on a compris sur un sujet la semaine dernière. Ça traînait dans des conversations, des notes, des onglets ouverts depuis trois mois. Invisible pour un agent, et de plus en plus invisible pour moi.

Je voulais un endroit qui tienne tout ça. Me décharger, surtout : une sorte de journal où écrire vite fait tout ce qui me passe par la tête, les trucs à tester, les articles à garder. Un endroit qui garde tout, structure tout, et lit pour moi.

Le réflexe qui ne marche pas

Mon premier réflexe : entasser.

Un dossier, tous les documents dedans, et on laisse l'IA chercher. C'est ce que font les fichiers déposés dans ChatGPT, un NotebookLM, ou n'importe quel système de RAG : à chaque question, le modèle repart des sources brutes, retrouve des morceaux, recompose une réponse. Ça fonctionne, il faut le dire.

Mais rien ne reste. Posez une question qui demande de croiser cinq documents : il refait le croisement entier, à partir de zéro. Le travail de synthèse n'est jamais gardé. Demain, même question, même effort, même résultat approximatif.

Et surtout : il faut savoir quoi demander. Une pile de documents attend qu'on lui pose la bonne question. Elle ne vient jamais vous voir.

L'idée que j'ai copiée : le LLM Wiki de Karpathy

À cette période, en avril, mon Instagram ne me montre que des influenceurs IA qui vendent monts et merveilles. C'est horrible. Mais au milieu de la bouillie, une tendance revient, le second brain, et elle a l'air vraiment intéressante. Je prends le tuto d'un influenceur lambda, juste pour récupérer les liens, et je remonte à la source : LLM Wiki, un texte d'Andrej Karpathy. Une page d'idées, sans outil derrière.

Le principe : plutôt que de laisser l'agent fouiller les sources à chaque question, on lui fait entretenir un wiki. Quand une source arrive, au lieu de l'indexer, il la lit, en extrait ce qui compte, et l'intègre dans une structure qui existe déjà. Il met à jour les pages concernées, révise les synthèses, signale là où la nouvelle information contredit l'ancienne.

La connaissance est compilée une fois, puis maintenue. Pas recalculée à chaque question.

Je l'ai archivé le 14 avril. On l'a adapté un peu, et testé direct.

Les premiers jours, c'est assez vide. Je balance des liens, des idées, et une série à regarder, pour vérifier que mes prompts font le taf. Ils le font : le brain se crée tout seul une section perso, avec une watchlist.

Ce que c'est, concrètement

Un repo. Du markdown, rien d'autre.

Quatre niveaux : une boîte de réception, les projets actifs, les domaines de long terme, les idées réutilisables. Et en dessous, une archive.

Ça ressemble à n'importe quelle organisation de notes. La structure est banale : tout tient dans les quatre règles.

L'archive est immuable. On n'édite jamais ce qui y est entré. On ne renomme pas, on ne supprime pas. C'est la règle la moins intuitive et la plus importante : elle sépare la source de l'interprétation. Une synthèse peut se tromper, être révisée, vieillir. La source reste ce qu'elle était. Sans cette séparation, le brain devient un texte qu'on réécrit en permanence, et au bout de six mois plus personne ne sait ce qui a vraiment été dit.

L'index ne peut pas dériver. Chaque ajout met à jour l'index et ajoute une ligne au journal, dans la même opération que le contenu. Pas après. Un index tenu à jour quand on aura le temps est faux en trois semaines, et un index faux coûte plus cher qu'un index absent, parce qu'on s'y fie.

On cherche avant d'écrire. Avant de créer une note, on vérifie si le sujet existe. S'il existe, on met à jour. Trois notes sur le même sujet, c'est pire que zéro : l'agent en trouve une, souvent la plus ancienne, et travaille avec.

Tout est relié. Chaque note pointe vers ses voisines. Une idée renvoie au projet qui l'a produite, un projet renvoie aux idées qu'il a servi à comprendre. C'est la différence entre une pile de fichiers et une mémoire : le chemin existe déjà quand on en a besoin.

Le flux réel

Le bot Telegram, on l'a monté en une heure avec Claude, juste après la configuration du brain. J'avais absolument besoin de pouvoir dropper depuis le téléphone. Un article intéressant : j'envoie le lien. Une idée : je tape trois mots. Un truc à faire : pareil. Dans la rue, au lit le soir, parce que j'ai souvent plein d'idées à la con la nuit. Tout atterrit dans la boîte de réception.

Plus tard, on traite. J'ai gardé le traitement manuel, exprès. Je pourrais l'automatiser, mais c'est un moment de prise de recul : on process tout, on regarde ce qu'on peut en faire. J'aime bien avoir des conversations avec mon brain, en fait.

Le traitement lui-même : Claude Code lit chaque contenu en entier, puis tranche : idée réutilisable, note de projet, domaine de long terme, ou bruit. Il extrait ce qui compte, le range au bon endroit, le relie aux notes voisines. L'original part à l'archive, daté. L'index est mis à jour. Une ligne dans le journal.

Rien de magique. Une skill, c'est-à-dire un processus écrit une fois, exécuté de la même façon à chaque fois.

Ce qui revient quand on ne demande rien

C'est là que ça devient fun. Je droppe un article sans un mot, le brain le lit, et s'il contient une solution à un problème que j'ai, ou quelque chose qui touche un projet en cours, il fait le lien et me le dit. Pareil pour un repo git, une skill à tester. Je n'ai posé aucune question. C'est exactement ce qu'une pile de documents ne fera jamais : elle attend qu'on l'interroge.

Un cas vraiment utile dans mon quotidien : les réunions.

Une visio client. Je récupère le transcript fait par Gemini dans Google Meet et je dépose le fichier dans la boîte de réception, je ne le relis pas.

Ce fichier fait plusieurs milliers de mots, et le premier tiers porte sur des écrans et du matériel informatique. La partie qui compte est enterrée au milieu : la plateforme choisie des mois plus tôt ne tiendra pas le nouveau périmètre, il faut trancher entre deux architectures, et une intégration avec un outil tiers conditionne tout le reste.

Ce qui ressort du traitement, c'est ça. La décision, la contrainte qui l'impose, les options comparées, les next actions. Rangé sous le projet du client, relié à ce qui existe déjà dessus.

Des mois plus tard, la question « pourquoi on est parti de cette plateforme » a une réponse écrite, datée, avec son raisonnement. Il me suffit de demander à mon agent, dans mon dossier de travail : il retrouve l'info instantanément.

Prendre des notes n'a jamais été le problème, je l'ai toujours fait, et la transcription automatique le règle de toute façon. Ce qui change tout, c'est où elles atterrissent : dans le brain, à côté de l'historique du projet, de son état d'avancement, des réunions précédentes. Et que tout ça ressorte au bon moment, quand on gère la suite avec le client.

Ce que ça ne fait pas encore

Tout ce que je viens de décrire, le brain le fait seul, dans son coin. Le jour où on le sort de là et où on le branche sur tout le reste, le code, les projets en cours, les clients, il se passe autre chose. C'est le sujet d'un prochain article.

L'installation, les trois commandes et ce que j'ai changé à la méthode d'origine, c'est dans un article à part, pour qui veut monter la sienne.

Entasser des fichiers, ça donne un grenier. Une mémoire, c'est autre chose : des fichiers stockés avec des règles qui les relient les uns aux autres, et des agents qui appliquent ces règles, jour après jour. Les règles sont les miennes. Le travail, c'est eux qui le font.