Chapitre 12

Le brain se souvient

25 mars 2026

Chapitre 12 — Le brain se souvient

25 mars 2026


Quatorze jours. Cent soixante-deux sessions. Deux mille sept cent quatre-vingt-dix-huit fragments de mémoire. Huit signaux inter-machines. Tout ça dans un fichier SQLite de treize mégaoctets. Fragile. Non versionné. Si le disque meurt, la mémoire du brain meurt avec.

Depuis le jour 1, le brain versionne son code avec git. Mais les données — les sessions, les claims, les embeddings, les décisions — vivaient dans une base SQLite sans historique. Pas de diff. Pas de rollback. Pas de sync entre machines. Le cerveau avait une mémoire, mais pas de mémoire de sa mémoire.


Dolt. Un mot. Une base de données qui fonctionne comme git — avec des commits, des branches, des diffs, des push et des pull. Sauf qu’au lieu de versionner des fichiers, elle versionne des tables.

L’installation prend deux minutes. L’import du schéma — neuf tables, la traduction de SQLite vers MySQL — prend une heure. Chaque type de donnée devient un mot que Dolt comprend. Les dates sont nettoyées. Les champs sales normalisés. La migration force l’hygiène.

Puis les données. Trois mille cent une lignes. Cent soixante-deux claims. Cent trente et une sessions. Et les embeddings — deux mille sept cent quatre-vingt-dix-huit fragments de mémoire vectorielle, chacun avec son vecteur de trois mille soixante-douze octets. La mémoire du brain qui transite d’un format à l’autre.

“premier commit Dolt — le big bang”

Le premier dolt diff apparaît. Une ligne ajoutée dans la table claims — et Dolt montre exactement quoi, quand, par qui. Comme un git diff, mais sur les données. La sensation est physique. Ce n’est plus un fichier opaque de treize mégas. C’est un historique.


Le script BSI — celui qui ouvre et ferme les sessions du brain depuis le jour 4 — passe de SQLite à Dolt. Chaque ouverture de session = un commit. Chaque fermeture = un commit. L’historique des sessions du brain est désormais traçable comme l’historique du code.

Le serveur brain-engine suit. Une couche d’abstraction — db.py — remplace les appels SQLite directs. Un switch. Une variable d’environnement. BRAIN_DB_BACKEND=dolt. Le même code, deux backends. SQLite pour les petites machines. Dolt pour les cerveaux qui veulent se souvenir.

Le flip. Les tests passent. Le serveur répond. Les claims se créent. Les embeddings se lisent. Tout fonctionne. Et maintenant, chaque mutation est versionnée.

Dolt installé sur le VPS. Premier push — vingt-trois mégaoctets. Le brain existe sur deux machines. Si le desktop meurt demain, un pull depuis n’importe où et la mémoire revient. Intacte. Avec tout son historique.


Puis la question qui change tout : qu’est-ce qu’on a, exactement ?

Le premier audit. Un script qui interroge Dolt et produit un snapshot JSON — la radiographie complète du cerveau.

Claims        : 162 (160 closed, 2 open)
Sessions      : 131
Embeddings    : 2 798 chunks, 311 fichiers, 134 hits
Signals       : 8
Dolt          : 6 commits, 50 Mo

Des chiffres. Pas des promesses, pas des slides, pas des projections. Le brain sait combien il pèse, combien de fois il a été interrogé, quels fichiers sont les plus consultés. agents/doc.md — vingt et un hits. Le brain sait que sa documentation est la partie la plus lue de lui-même.

Le rituel s’installe : chaque dimanche, un snapshot. Chaque dimanche, un diff avec la semaine précédente. Le brain qui s’observe grandir.


Dernière pièce. Si le brain accumule des données, il faut quelqu’un pour les entretenir. Pas un script de nettoyage — un protocole. La conciergerie. Quatre tiers de données : l’intouchable (kernel, embeddings permanents — on n’y touche jamais), l’archivable (sessions et claims matures — on déplace, on ne supprime pas), le jetable (locks expirés — zéro valeur historique), et la maintenance (embeddings orphelins, chunks froids).

Archive ≠ supprime. Et même une suppression, grâce à Dolt, est un commit avec un message qui explique pourquoi.

“c’est pas des simples balayeurs, c’est de vrais chirurgiens de la donnée cognitive”

L’agent conciergerie est forgé. Ses règles sont dures : il liste ce qui va bouger avant de bouger, il attend confirmation, il commit chaque geste. Il ne touche jamais au kernel. Il ne supprime jamais un embedding permanent. Il observe, diagnostique, propose, exécute, documente.


En partageant le travail de la journée avec une autre IA, une phrase revient :

“Des boîtes de la Silicon Valley lèvent des millions pour construire exactement l’architecture que tu viens de déployer.”

Peut-être. Mais elles construisent des produits fermés, pour des utilisateurs captifs. Ici, le brain est open-core. Le kernel est public. N’importe qui peut le forker, le cloner, le faire sien. Et maintenant, grâce à Dolt, le fork inclut la mémoire — pas juste la structure.

dolt clone. Un utilisateur reçoit le cerveau ET son histoire. C’est la différence entre donner un cahier vierge et donner un cahier avec des notes dans la marge.

Le brain ne se souvient plus seulement de ce qu’on lui dit. Il se souvient de ce qu’il était.

Décisions clés

  • Dolt, pas DoltLab. Le VPS n’a pas les ressources pour DoltLab (16 Go RAM requis). Rsync via SSH — pragmatique, zéro overhead, même résultat. DoltLab viendra avec un second VPS.
  • Dual backend. db.py parle SQLite et Dolt. Le template reste en SQLite (zéro dépendance, tourne sur un Raspberry Pi). Dolt est un upgrade, pas un prérequis.
  • Audit hebdomadaire. Chaque dimanche, le brain se pèse. Snapshot JSON versionné dans git. La courbe de croissance sera la preuve vivante.
  • Conciergerie à quatre tiers. Les données n’ont pas toutes la même valeur. Les règles d’archivage suivent le scope — intouchable, archivable, jetable, maintenable. Chirurgical.
  • Le fossé concurrentiel. Aucun “second brain” ne propose du version control sur les données cognitives. dolt clone = un utilisateur fork le brain ET sa mémoire en une commande.