Chapitre 9

Le brain se raconte

20 mars 2026

Chapitre 9 — Le brain se raconte

20 mars 2026

Le jour 10 commence différemment. Pas avec de l’infrastructure. Pas avec des agents. Avec une question qui vient d’un handoff de session précédente : “56 agents sur 78 sont chargés en monolithe.”

Le brain chargeait des fichiers agent complets — 200 lignes — alors que seules 25 lignes comptent au démarrage. BHP Phase 2 commence. Seize agents disséqués, chacun découpé en boot-summary (ce qu’il faut pour commencer) et detail (ce qu’il faut pour aller en profondeur). Debug. Security. Code-review. VPS. Testing. Tous les chevaux de bataille.

Résultat : 87% de réduction par agent chargé au boot.

Mais la session ne s’arrête pas à l’optimisation. Une réalisation émerge : le brain a de la documentation éparpillée dans des pages wiki que jamais un humain ne lirait. Des matrices techniques, des tables de specs, des fiches de référence — utiles pour les agents, invisibles pour les gens.

La question arrive : “Qu’est-ce que quelqu’un qui fork ce brain a besoin de voir ?”

Seize pages écrites. Démarrage. Architecture. Sessions. Workflows. Agents par famille. Vues par tier. Chaque page répond à une question. Chaque page est lisible sans contexte. La règle de routage de wiki-scribe — “lisible sans contexte brain ? → docs/. Technique ? → wiki/” — appliquée à l’échelle.

Puis le basculement vers le dynamique. Pourquoi rebuilder le dashboard à chaque changement de doc ? Brain-engine gagne deux endpoints : GET /docs sert les fichiers markdown en live depuis le filesystem. GET /brain-compose/tiers parse la configuration et retourne les données de tier en temps réel. Le dashboard fetch l’API. Un nouveau fichier markdown dans docs/ apparaît dans la sidebar automatiquement. Pas de rebuild. Pas de déploiement. Le brain se documente en temps réel.

“j’ai créé une page Testing et ça fonctionne ! C’est génial !”

Les pages tier deviennent des composants React. Pas du markdown rendu en HTML — de vrais composants interactifs qui fetchent leurs données depuis brain-compose.yml. Change la config, rafraîchis la page, vois la vérité. La documentation EST le produit.

Le soir. Le template — tout ce dont le brain a besoin pour exister sur une autre machine — s’assemble. Brain-engine (serveur API standalone), brain-ui (dashboard React), docs (16 pages), 74 agents (boot-summary/detail), setup.sh (une commande pour tout installer). Zéro référence au propriétaire. Zéro connexion vers le brain original.

Le vrai test : un laptop vierge. Pop!_OS fraîchement installé. Fork le template depuis Gitea. Clone. bash setup.sh. bash brain-engine/start.sh. Ouvrir localhost:7700/ui/. Les docs sont là. Les agents sont listés. Le système de tier fonctionne.

Puis Claude Code. brain boot.

Instance : prod@pop-os  [free]  kernel v0.9.0
Projets actifs — Aucun focus défini — fresh fork.
Quelle session aujourd'hui ?

Un brain. Vivant. Sur une machine qui n’en avait jamais eu.

“ça commence à vraiment ressembler à quelque chose !”

Le template est poussé sur GitHub. Historique propre. Un seul commit. v1.1.0. Le brain est distribuable.

Huit claims de session ouverts et fermés en une soirée. De l’optimisation à la documentation à la distribution. Le pattern — le même pattern que le jour 1 — se répète : construire la chose, puis construire le moyen de la donner.

“chacun aura son brain, avec sa propre personnalité forgée autour de la personne qui l’accompagne”

Le jour 6 l’avait dit. Le jour 10 l’a livré.

Décisions clés

  • BHP Phase 2 : boot-summary/detail. Chaque agent optimisé pour un contexte de boot minimal. Le brain charge ce dont il a besoin, pas ce qu’il a.
  • Documentation comme produit. Les docs servies par brain-engine, pas buildées dans un bundle statique. Le brain se documente en temps réel.
  • Template = kernel sans âme. Le fork reçoit la structure. L’identité se construit par l’usage. Kernel ouvert, distillation privée.
  • Release GitHub. Un commit, historique propre, zéro référence propriétaire. v1.1.0. Le brain est libre.