Ce que Jarvis m’a appris : 4 concepts d’assistant IA open source transposés sur mon homelab
Comment un assistant IA open source (AGPL-3.0) m’a poussé à repenser la mémoire, l’autonomie, la fiabilité et la gouvernance de mon propre assistant personnel auto-hébergé.
Introduction
J’ai un assistant personnel auto-hébergé basé sur Hermes Agent, qui tourne sur mon homelab (un LXC Proxmox). Il gère ma messagerie, ma veille RSS, ma domotique, mon coffre de notes Obsidian, et publie même sur ce blog.
Récemment, je suis tombé sur Jarvis OS, un assistant IA open source (licence AGPL-3.0) développé par Barthélemy Houot. En l’étudiant, j’ai identifié 4 concepts qui manquaient à mon installation et qui valaient la peine d’être transposés :
- Mémoire vivante (Memory Kernel) — des faits atomiques, datés, sourcés, au lieu d’un gros bloc de texte.
- Proactif gouverné — des initiatives à niveau d’autonomie, pas juste des scripts figés.
- Mission Engine — des tâches planifiées, vérifiées à chaque étape, reprises après crash.
- Gouvernance transversale — un audit immuable de tout ce que fait l’assistant.
Cet article raconte ce que j’ai retenu de chacun, et comment je les ai (ou non) transposés sur Hermes. C’est un retour d’expérience honnête : tout n’est pas allé aussi vite que prévu, et j’ai dû faire des choix.
⚠️ Note de licence : Jarvis OS est sous AGPL-3.0. Je m’inspire de ses concepts (les idées ne sont pas protégées par le droit d’auteur), mais je réimplémente tout de zéro dans mon environnement privé. Je ne copie pas son code. C’est important : si un jour je publiais mon code, il faudrait s’assurer de ne pas avoir repris de code AGPL ligne à ligne.
Contexte : mon assistant avant Jarvis
Avant cette réflexion, mon assistant Hermes avait déjà pas mal de choses :
- Une mémoire built-in (system prompt) avec mes préférences et les faits durables — mais saturée (6000/6000 caractères).
- Des cron jobs pour la veille, les sauvegardes, le watchdog mail.
- Un RAG (Qdrant + bge-m3 + deepseek) pour interroger mon coffre Obsidian et mes documents.
- Des skills (procédures réutilisables).
- Un plan mode et un outil todo pour structurer les tâches.
Mais en regardant Jarvis, j’ai réalisé que plusieurs briques étaient absentes ou incomplètes :
| Brique | État réel chez moi |
|---|---|
| Mémoire structurée (faits atomiques) | Code écrit mais jamais branché |
| Autonomie / budget des tâches | Absent — cron binaires |
| Vérification d’étape + reprise après crash | Partiel — planifie mais ne vérifie pas |
| Audit immuable des actions | Absent |
Le plus frustrant : le Memory Kernel était déjà écrit (phases 1-7), mais inactif. C’était un travail d’intégration, pas de développement.
Concept 1 — Mémoire vivante (Memory Kernel)
Ce que fait Jarvis
Jarvis ne mémorise pas en vrac. Il extrait des faits atomiques (« Barth vise un marathon sub-3h »), les date, les source (quel échange les a produits), les renforce quand il les ré-entend, les archive quand ils sont contredits — sans jamais les supprimer. Une base SQLite unique est la source de vérité, et un miroir Markdown lisible (compatible Obsidian) en donne une vue inerte.
Chaque nuit, AutoDream + ConsolidationAgent repassent sur les sessions récentes pour extraire les faits manqués en temps réel.
Ce que j’ai fait
J’avais déjà un Memory Kernel Hermes en code (CRUD + FTS5 + scoring, pipeline d’ingestion LLM, miroir Obsidian, AutoDream, connecteurs radio/lectures/OSINT). Le travail était de le brancher :
- Activer le plugin :
memory.provider = memory-kernel(remplace l’ancien provider vectoriel). - Peupler la base : lancer l’ingestion sur les échanges passés + les sources (radio, lectures, OSINT).
- Cron micro-dream : toutes les 2h, un job lit les échanges récents et en extrait des faits.
Résultat : la base est passée de 0 à 29 faits actifs (24 seedés + 5 ingérés par LLM), et la saturation mémoire est en voie de résolution — les faits structurés remplacent les strings plates du system prompt.
Le piège que j’ai rencontré
Le garde-fou de sécurité des cron jobs bloquait les scripts Python contenant des opérateurs Path / (vus comme des exécutables). La solution : utiliser joinpath() au lieu de /. Un détail, mais qui m’a coûté du temps de debug.
Concept 2 — Proactif gouverné
Ce que fait Jarvis
Jarvis ne « pousse pas juste des notifs » : il entreprend des initiatives gouvernées. Chaque initiative porte un déclencheur, un objectif, un coût max (tokens/temps/argent), un niveau d’autonomie (0-5) — 0 = répondre seulement, 5 = publier/payer/contacter (validation humaine obligatoire) — et un état suivi en continu.
- Collectors : captent les signaux (météo, actualités RSS, trackers).
- Command Center : la vue unifiée de toutes les initiatives en cours.
- Curator nocturne : un job de maintenance qui produit un rapport et propose des patches (facts contradictoires, skills inutilisées, coûts, erreurs récurrentes). Il propose, l’humain valide.
Ce que j’ai fait (partiel)
Chez moi, les cron jobs étaient binaires (déclenchés ou non), sans notion d’autonomie ni de budget. J’ai commencé par le plus rentable :
- Réparé un job en erreur : le « Analyse hebdomadaire coffre » échouait en HTTP 403. La cause : une clé
OLLAMA_API_KEYdans.env(sans accès au modèle) écrasait la bonne clé deconfig.yaml. Une fois.envcorrigé, le job est repasséok. - Créé un Curator nocturne : tous les jours à 6h, il inspecte les jobs, signale ceux en erreur, et reste silencieux si tout va bien. Livraison sur Matrix.
Reste à faire : le modèle d’autonomie 0-5 (validation humaine par niveau de risque) et le Command Center. C’est le concept le plus long à transposer.
Concept 3 — Mission Engine
Ce que fait Jarvis
Le Mission Engine transforme une demande en mission planifiée, vérifiée à chaque étape, avec reprise après crash. Trois types de vérification :
| Type | Question | Exemples |
|---|---|---|
| structural | Le format est-il bon ? | fichier existe, JSON valide, non vide |
| deterministic | Le résultat respecte-t-il une règle exacte ? | len(result) >= 3, "ok" in result |
| semantic | Le contenu a-t-il du sens ? | question oui/non via LLM |
Ce que j’ai fait
Le todo tool natif d’Hermes est en mémoire uniquement (pas de persistance, pas de vérification). J’ai donc écrit un module Python autonome mission_engine dans mon workspace :
- 3 types de vérification : structural (fichier/JSON/non-vide), deterministic (expression Python sûre sur le résultat), semantic (LLM oui/non, avec repli heuristique).
- Garde de sécurité : les expressions déterministes refusent les appels dangereux (
open,import,exec,eval,os.,subprocess). - Persistance JSONL atomique dans
~/.hermes/missions/+last_validated_steppour la reprise. - Testé : les 3 types de vérif + la garde + la reprise après crash (crash simulé à l’étape 3 → reprise → mission complète 3/3).
C’est un module autonome (pas d’API HTTP) : on l’appelle par import direct ou via CLI. Je ne l’ai pas dupliqué ailleurs — c’est à moi de le maintenir.
Concept 4 — Gouvernance transversale
Ce que fait Jarvis
Tout accès filesystem/réseau passe par un gate composite (risque × catégorie × budget) avec audit immuable. Rien ne se fait sans validation si ça dépasse le seuil.
Ce que j’ai fait
Hermes a déjà des garde-fous natifs (approbation d’écriture mémoire, confirmation des commandes dangereuses). J’ai ajouté ce qui manquait :
- Hook
audit-actions: un journal append-only JSONL de toutes les actions (agent:start/step/end) avec un niveau de risque 0-5 par outil. Chargé au démarrage du gateway. - Gate composite : je me suis appuyé sur le mécanisme natif robuste d’Hermes (Tirith +
hooks_auto_accept: false+ liste de commandes dangereuses) plutôt que d’en réinventer un. Pas de doublon. - Curator étendu : il lit le journal d’audit et signale les actions à risque ≥ 4 des 24h dans le rapport nocturne.
Reste à faire : le suivi de budget (coûts tokens/temps par initiative).
Ce que j’en retiens
1. Le plus rentable d’abord
Le Memory Kernel était le plus mûr (code prêt) et le plus impactant (résout la saturation mémoire). C’est par là qu’il fallait commencer. Le Curator nocturne a apporté de la valeur immédiate (détection des jobs en erreur).
2. Réparer avant de construire
Le job en 403 m’a rappelé une règle simple : priorité à réparer l’existant avant d’ajouter de nouveaux services. Un .env mal configuré valait mieux qu’un nouveau composant.
3. S’inspirer, pas copier
Jarvis est une excellente source d’idées, mais je réimplémente les concepts dans mon environnement, avec mes contraintes (homelab privé, simplicité, coûts maîtrisés). La licence AGPL-3.0 de Jarvis ne m’empêche pas de m’inspirer des concepts — elle m’empêcherait seulement de copier son code et de le redistribuer sans publier mes modifications.
4. La simplicité est une force
À chaque fois que quelque chose devenait « très lourd », je l’ai simplifié. Le Mission Engine est un module Python autonome, pas un service HTTP. Le gate composite s’appuie sur le natif. Moins de pièces = moins de pannes.
Et la suite ?
- Memory Kernel : continuer à peupler la base, ajouter le deep dream nocturne.
- Proactif : implémenter le niveau d’autonomie 0-5 et le Command Center.
- Gouvernance : ajouter le suivi de budget.
- Mission Engine : l’utiliser pour les tâches critiques qui doivent survivre à un crash.
Si vous avez un assistant IA auto-hébergé, je vous encourage à regarder Jarvis OS — pas pour le copier, mais pour les questions qu’il pose : comment votre assistant mémorise-t-il ? jusqu’où peut-il agir seul ? comment savez-vous qu’il a bien fait ce qu’il devait faire ?
Cet article a été rédigé avec l’aide de mon assistant Hermes, qui a aussi implémenté la plupart des concepts décrits. Le code source et la documentation complète sont dans mon coffre Obsidian.