Donner une mémoire à son assistant IA — le Memory Kernel

Le problème de la mémoire plate

Si vous utilisez un assistant IA (ChatGPT, Claude, Hermes…), vous avez déjà vécu ça : vous lui dites quelque chose d’important, il répond parfaitement, puis dans la conversation suivante, il a tout oublié. Vous devez tout répéter.

C’est normal. La plupart des assistants ont une mémoire plate : un bloc de texte qu’on injecte dans le prompt système à chaque début de session. Chez moi, ça ressemble à ça :

« 
User pref: go sauf suppr doc/paiement/pub
Cat Rouzé TG 5782530975
Modèle par défaut: deepseek-v4-flash
HA GTV (ha.rouze.eu) + HA Sorède
Email: 3 comptes (hermes, jeanpaul, rouzejp)
...
`

Ça marche, mais c'est limité :

• Pas de structure : c'est du texte libre, pas un graphe de faits
• Pas de fiabilité : une information répétée 10 fois a le même poids qu'une hypothèse non vérifiée
• Pas d'obsolescence : un projet terminé depuis 6 mois reste dans la mémoire comme s'il était actif
• Pas de relations : impossible de dire « ce fait contredit celui-ci » ou « cette information confirme celle-là »
• Pas de visibilité : la mémoire est invisible dans le coffre Obsidian, pas de navigation possible
• Taille limitée : ~2000 caractères, au-delà on rogne

J'ai donc décidé de construire un Memory Kernel — un système de mémoire structurée, directement inspiré du projet Jarvis-OS que j'ai étudié en détail.

Le concept : des faits atomiques

Au lieu d'un bloc de texte, on stocke des faits atomiques : sujet → prédicat → objet.

`
jean-paul → prefers → reponses-concises
jean-paul → uses → ollama
jean-paul → works_on → assistant-perso
jean-paul → values → simplicite
hermes → communicates_as → orchestrateur
`

Chaque fait a :

• Une catégorie (identité, préférence, projet, habitude, contrainte, décision…)
• Une confiance (0.0 à 0.99) qui augmente à chaque confirmation
• Une politique d'obsolescence (certains faits durent toujours, d'autres expirent en 2 semaines)
• Une importance (0 à 1) notée par l'assistant lui-même
• Un statut (actif, remplacé, contredit, archivé)

L'architecture

`
┌──────────────────────────────────────────────┐
│ Memory Kernel │
│ │
│ ┌────────┐ ┌────────┐ ┌───────────────┐ │
│ │ facts │ │events │ │ fact_relations │ │
│ └────────┘ └────────┘ └───────────────┘ │
│ ┌──────────────────┐ ┌──────────────┐ │
│ │ fact_observations│ │ facts_fts │ │
│ └──────────────────┘ └──────────────┘ │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ Miroir Obsidian (SQLite → Markdown) │ │
│ └──────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ Pipeline d'ingestion (LLM → faits) │ │
│ └──────────────────────────────────────┘ │
└──────────────────────────────────────────────┘
`

1. SQLite — la source de vérité

Quatre tables, un index FTS5. Rien de plus.

• events : log immuable de tout ce qui arrive. On ne supprime jamais un event.
• facts : les faits atomiques avec leur métadonnées (confiance, catégorie, statut…)
• fact_observations : chaque confirmation, affaiblissement ou correction d'un fait
• fact_relations : liens entre faits (contredit, remplace, soutient, lié à)

Règle d'or : on ne supprime jamais un fait. S'il est contredit, il passe en statut superseded avec une relation pointant vers le nouveau. Traçabilité totale.

2. Vocabulaire fermé

Pour éviter le bruit, les prédicats et catégories sont limités à une liste fixe :

| Prédicat | Usage | Exemple |

prefers	Préférence	jean-paul prefers reponses-concises
uses	Outil	jean-paul uses ollama
works_on	Projet	jean-paul works_on assistant-perso
values	Valeur	jean-paul values simplicite
decided	Décision	jean-paul decided memory-kernel-prioritaire
struggles_with	Contrainte	jean-paul struggles_with internet-limite

13 catégories avec des durées de vie différentes : identity ne expire jamais, goal expire en 2 semaines, preference en 3 mois…

3. Pipeline d'ingestion

C'est le cœur intelligent. Après chaque échange significatif :

1. Log : l'échange est enregistré dans events
2. Extraction LLM : un prompt spécialisé extrait 0-3 faits atomiques
3. Réconciliation : pour chaque fait candidat, l'assistant décide :

• Déjà connu → +0.05 de confiance, +1 au compteur de support
• Contredit → l'ancien passe superseded, le nouveau est créé avec une relation
• Nouveau → création pure

4. Scoring au retrieval

Quand l'assistant a besoin de sa mémoire, il ne charge pas tout. Il score les faits :

`
score = importance × récence × pertinence × confiance
`

• Importance : notée par le LLM à l'ingestion
• Récence : décroissance exponentielle selon la politique de la catégorie
• Pertinence : recherche BM25 via FTS5
• Confiance : 0.55-0.99

Seuls les faits les mieux notés sont injectés dans le contexte. La mémoire ne déborde jamais.

5. Miroir Obsidian

Les faits actifs sont exportés automatiquement en Markdown dans le coffre Obsidian :

`
20_Concepts/Sciences/ia/Memory/
├── user/
│ ├── preferences.md
│ ├── projects.md
│ ├── goals.md
│ ├── habits.md
│ ├── constraints.md
│ ├── decisions.md
│ └── identity.md
└── hermes/
├── persona.md
└── corrections.md
« 

Sens unique : SQLite → Markdown. On n’édite pas le miroir à la main. Pour corriger un fait, on passe par une commande qui crée un événement de correction. Prochaine régénération, le miroir reflète la correction.

Ce que ça change concrètement

| Avant (mémoire plate) | Après (Memory Kernel) |

Bloc de texte ~2000 caractères	Graphe de faits illimité
Pas de notion de fiabilité	Confiance 0.0-0.99
Pas d’obsolescence	Decay par catégorie
Pas de relations entre faits	Supersession, contradiction, support
Invisible dans Obsidian	Miroir Markdown navigable
Impossible à corriger proprement	Corrections tracées via events

Et le coût ?

L’extraction LLM coûte quelques tokens par échange. J’utilise DeepSeek (modèle local via Ollama) pour ça — pas d’appel API payant. Le stockage SQLite pèse quelques centaines de kilo-octets pour des milliers de faits. Le cron de régénération du miroir tourne une fois par heure.

Le tout tient sur un VPS à 5€/mois.

Et après ?

Le Memory Kernel est la première brique d’un projet plus large : l’Assistant Perso. Les prochaines étapes :

• AutoDream : une analyse nocturne des sessions de la journée pour en extraire les apprentissages durables
• Skill Lab : détection automatique des patterns réussis pour les transformer en skills Hermes réutilisables
• Gouvernance : validation explicite pour les opérations sensibles, avec graduation de l’autonomie

Tout le code est open source, sur GitHub :

👉 github.com/rouzejp/hermes-assistant-etendu

Le dépôt contient l’implémentation complète du Memory Kernel (Python, SQLite, FTS5), les tests, la documentation, et les skills Hermes associés. C’est un projet en construction — contributions, issues et retours bienvenus.