Chapitre 10

Le brain se prépare à rencontrer le monde

21 mars 2026

Chapitre 10 — Le brain se prépare à rencontrer le monde

Sources vérifiées : git log brain 2026-03-21 + git log brain-ui 2026-03-21 Même journée que le chapitre 9 — angle différent : la simulation de fork. Commits clés : 699baec (chiffres corrigés) · d7c346c (symlinks supprimés) · 803abf3 (auto-detect API) · 62b88cc (CLAUDE.md template sync)

Le template existait. Le laptop avait booté. Mais distribuable et utilisable par quelqu’un d’autre sont deux phrases différentes. La question arrive dans la même session que le chapitre 9 : si un ami fork le template ce soir, qu’est-ce qui casse ?

La réponse : presque tout.

L’audit de la surface

Premier constat : le trio d’agents forgé plus tôt dans la session — guide, catalogist, pathfinder — existait sur le desktop mais n’avait jamais été commité. Les agents d’onboarding, censés accueillir un nouvel utilisateur, étaient invisibles pour quiconque forkait. Commit. Push. Le fix le plus embarrassant de la journée.

Les chiffres qui mentent

Les docs. La vitrine sur brain.tetardtek.com affichait “14 agents” en tier free — c’était 17 depuis l’ajout du trio. “75 agents” en full — c’était 81. Les chiffres dans le markdown ne se mettent pas à jour tout seuls.

699baec (19:57) — docs: polish agents + chiffres corriges + trio onboarding + lien story.tetardtek.com

Correction. Et une question qui manquait en haut de la page agents : pourquoi un brain plutôt que Claude seul ?

La réponse tient en trois lignes : Claude repart de zéro à chaque session. Le brain, non. Tes règles, ta stack, tes décisions persistent. Ton contexte survit.

C’est la phrase qui doit être là dès qu’un visiteur arrive. Pas les specs — le pourquoi.

La simulation de fork

Le vrai travail commence quand on simule un fork. Le laptop — machine sandbox — joue le rôle du premier utilisateur. Clone. bash setup.sh. Build.

Crash.

Les fichiers dans le dashboard étaient des symlinks vers des chemins absolus du desktop. Sur le laptop, ces chemins n’existent pas. Vite échoue. Le build est mort avant de commencer.

d7c346c (20:20) — fix: supprimer symlinks brain-ui/public/docs/ — docs servies live par brain-engine

Les symlinks — vestiges d’un mode statique qui n’a plus de raison d’être. Supprimés. Le build passe.

Le 404 invisible

Dashboard ouvert. Badge “static”. Toutes les pages en 404. L’API fonctionne — une requête directe retourne 15 fichiers, contenu complet. Mais le navigateur ne voit rien.

Première hypothèse : la variable d’environnement API est vide, les requêtes partent en relatif. Fix. Rebuild. Toujours 404.

DevTools ouverts. Les requêtes partent vers un chemin qui n’existe qu’en production, derrière un reverse proxy. En local, sans proxy, c’est un 404 garanti.

“si quelqu’un qui fork doit directement bidouiller on est pas bien”

803abf3 (21:14) — fix: docs.html auto-detect API path — fonctionne local ET derriere proxy

Le fix : auto-détection. La page essaie les deux chemins possibles — local direct et reverse proxy. Le premier qui répond gagne. Zéro configuration. Fonctionne partout.

La fuite sur la vitrine

Dernier tour. La vitrine VPS. Refresh. Les onglets Infra et Secrets affichent les vrais services de production et les vrais noms de clés secrètes. L’instance template exposait l’infrastructure du brain prod.

Les onglets passent en disabled avec un badge “soon”. Plus de fuite. La vitrine est safe à partager.

Le CLAUDE.md du fork

Un détail qui n’en est pas un :

62b88cc (15:29) — fix: CLAUDE.md template sync + brain boot depuis n'importe quel cwd

Le CLAUDE.md — le fichier que Claude Code lit en premier — devait fonctionner depuis n’importe quel répertoire de travail. Pas seulement depuis /home/tetardtek/Dev/Brain. Depuis n’importe quel chemin, sur n’importe quelle machine. Le fork d’un inconnu qui s’appelle pas tetardtek et qui n’a pas le même home directory.

Fin de journée. Trois environnements testés, trois environnements live.

Desktop (prod)  → dashboard local  → live
Laptop (fork)   → dashboard local  → live
VPS (vitrine)   → dashboard public → live

Le template n’a pas encore quitté le cercle. Mais le cercle a été testé. Chaque friction trouvée — symlinks, chemins hardcodés, API assumptions, drift de code, fuites de données — est une friction éliminée pour le prochain humain qui tapera bash setup.sh.

“le fork doit juste marcher”

Pas encore. Mais bientôt.

Ce qui a été corrigé

Bug trouvé	Fix	Commit
Trio agents non commités	Push des agents + sync template	`1dc3d4e`
Chiffres docs périmés (14→17 free, 75→81 full)	Comptage réel + correction	`699baec`
Symlinks vers chemins absolus desktop	Supprimés, docs servies live	`d7c346c`
API path hardcodé reverse proxy	Auto-detect local/proxy	`803abf3`
CLAUDE.md path-dependent	Boot depuis n’importe quel cwd	`62b88cc`
Onglets Infra/Secrets exposent la prod	Disabled + badge “soon”	—

Décisions clés

Auto-détection API. Le dashboard détecte automatiquement s’il est derrière un proxy ou en local. Zéro config pour l’utilisateur.
setup.sh crée tout. .env.local, build npm, brain.db — un fork qui fait bash setup.sh doit avoir un brain fonctionnel. Pas de bidouille.
Vitrine sanitisée. Les onglets owner sont désactivés sur le template. La démo montre les capacités sans exposer les données.
Le test E2E comme méthode. Simuler le parcours utilisateur sur une machine sandbox avant de distribuer. Chaque bug trouvé = une friction en moins.
Le “pourquoi” avant le “comment”. La première chose que voit un visiteur ne doit pas être une spec technique — c’est la raison d’exister.

Citations

“si quelqu’un qui fork doit directement bidouiller on est pas bien”

“le fork doit juste marcher”