Igor — Guillaume Samard

Comment ça est né

Igor est né d'un constat simple : mes idées, mes décisions, mes retours d'expérience, c'est partout et ça s'échappe. Dans un chat, sur une montre, dans un message, dans un appel. Le problème n'était pas la capture — c'est que je pouvais capturer partout — le problème était que rien ne s'assemblait.

L'idée est montée en couches : d'abord une mémoire (capturer et retrouver par sens, pas par mot), puis des mains (déléguer à des agents qui codent, cherchent, agissent), puis un cockpit (voir l'état de tout en temps réel). Igor, c'est la somme de ces couches, et il est le projet qui relie tous les autres — c'est lui qui les pilote, qui s'en souvient et qui les relie.

Le contexte

Igor est un orchestrateur personnel qui capture ce que je dis — dans un chat, sur une montre, par message — et qui en fait quelque chose : il cherche, se souvient, délègue à des agents, rapporte. Tout tourne sur mon VPS, en Python asyncio, avec du streaming SSE et du WebSocket pour le temps réel.

Le cœur, c'est le second brain : chaque pensée est capturée, indexée, stockée en SQLite avec un miroir Obsidian pour la lecture humaine, et récupérée plus tard par recherche sémantique plutôt que par mot-clé. Je parle, il se souvient, il répond avec le bon contexte. Les embeddings sont calculés côté modèle, et le miroir Obsidian rend le tout navigable sans toucher à la base.

Autour du cerveau, il y a un vrai système multi-agents : des modèles distants (Claude, Codex), des modèles locaux (Qwen, Gemma) routés derrière une API OpenAI-compatible via un provider Ollama, des pipelines multi-phases, un mission control et un dashboard unifié qui affiche l'état de tout en temps réel — chaque appel laisse une trace que l'on peut relire et rejouer.

Ce qui distingue Igor d'un simple chatbot, c'est la mémoire de long terme et la délégation. Un chatbot oublie à la fin de la session ; Igor, lui, se souvient de ce que j'ai fait il y a trois mois, le retrouve, et peut m'enchaîner dessus. Et quand une tâche est grosse, il ne la fait pas seul : il la découpe et la délègue.

Le point dur

Rendre la mémoire de long terme fiable et rapide

Le point dur, c'est le retrieval : retrouver la bonne pensée au bon moment, vite, et pas la première qui vient. Une recherche par mot-clé échoue dès que la formulation change ; une recherche vectorielle brute renvoie du bruit. J'ai dû combiner index sémantique, reranking et filtre temporel pour que le bon contexte remonte, en restant sous la seconde de latence sur du SQLite local.

Le deuxième point dur, c'est de faire tourner des modèles locaux sans qu'ils plombent la latence : préchargement, contexte borné, streaming vérifié, et un routing qui envoie les taches faciles aux petits modèles et les taches dures aux gros. C'est tout le routing LiteLLM qui existe pour ça.

Fonctionnalités

Capture & second brain SQLite + miroir Obsidian

Chaque pensée est capturée, indexée et récupérée par recherche sémantique, pas par mot-clé. C'est la mémoire de long terme du système.

Multi-agents Claude · Codex · locaux

Igor délègue à des agents spécialisés. Les modèles distants et locaux sont unifiés derrière un même contrat d'appel.

Modèles locaux Qwen · Gemma

Un provider Ollama branché directement : host, taille de contexte (num_ctx), mode « think », resynchronisation, streaming vérifié.

Pipelines multi-phases V3 / V4

Des chaînes de travail planifiées, codées, testées et déployées, avec rôles séparés et scoring qualité — voir la page Pipelines.

Mission control dashboard unifié temps réel

Un écran de contrôle unique : tâches, agents, notifications, état du système. Tout est observable, chaque appel est tracé.

Notifications & présence SSE · push

Les événements remonter en temps réel vers le web et la montre (Brain Addon), avec un service de notification en foreground.

Arbitrages techniques

SQLite plutôt qu'un vecteur DB Un seul fichier, zéro service à faire tourner, backup trivial sur un VPS. Contrepartie : Le reranking est fait en application, pas en base — plus de code, mais zéro infra.

Un miroir Obsidian à côté de SQLite Je veux pouvoir ouvrir mes notes sans API, avec un outil que je connais déjà. Contrepartie : Double écriture à synchroniser ; j'ai dû accepter que le miroir soit en écriture, la base en lecture.

Modèles locaux routés en premier Coût nul, données privées, latence maîtrisée pour le simple. Contrepartie : Il faut du matériel et du tuning ; le gros reste sur API distante quand c'est nécessaire.

Un contrat d'appel unique pour tous les agents Déléguer sans savoir si c'est Claude, Codex ou Qwen derrière. Contrepartie : Le contrat doit rester le plus petit dénominateur commun, donc certains modèles perdent des capacités.

Stack technique

Pythonasyncio · SSE · WebSocket

StockageSQLite + miroir Obsidian

AgentsClaude · Codex · Ollama (LiteLLM)

LocalQwen · Gemma · num_ctx · think

RéseauVPS hserver · Tailscale

Observabilitétraces · replay · dashboard

En chiffres

0providers unifiés

0modèles locaux

100%tracé

<1 sretrieval cible

temps réelmission control

Parcours du projet

Base
Capture des pensées, indexation, second brain SQLite + Obsidian, retrieval sémantique.
Multi-agents
Intégration de Claude et Codex derrière un contrat commun, délégation de tâches.
Modèles locaux
Provider Ollama branché (Qwen, Gemma), routing LiteLLM, streaming vérifié.
Pipelines & mission control
Chaînes multi-phases, dashboard unifié temps réel, notifications et observabilité.
Écosystème
Brain Addon, Tether, Brain Map 3D et Brain Addon branchés sur le noyau Igor.

Ce que ça a rendu

01
Mémoire qui tient
Je retrouve, par sens, ce que j'ai fait il y a des mois — et je peux m'enchaîner dessus.
02
Production déléguée
Les pipelines (V3/V4) produisent du code de bout en bout, en se basant sur Igor.
03
Presque tout en dérive
Brain Addon (montre), Tether (widgets), Brain Map (visualisation) s'appuient sur Igor.