La plupart des assistants IA ont une mémoire de poisson rouge. Chaque session repart de zéro. Vous expliquez à nouveau votre contexte professionnel, vos préférences, vos projets en cours. Au bout d’un moment, c’est vous qui travaillez pour l’IA, pas l’inverse.
OpenHuman prend le problème à l’envers. L’idée de départ est simple : construire un assistant qui se souvient vraiment — en canonisant vos données personnelles et professionnelles dans un arbre de résumés hiérarchique stocké localement, mis à jour en continu via des intégrations OAuth, et compressé intelligemment avant d’atteindre le LLM. Architecturalement, c’est différent d’un simple RAG avec un vecteur-store.
Le projet est inspiré du pattern “LLM Knowledgebase” documenté par Andrej Karpathy, et construit en Rust avec Tauri pour l’encapsulation desktop. Il est en early beta — 7 500 étoiles GitHub en quelques semaines, ce qui suggère que le problème résonne. Mais “early beta” veut vraiment dire quelque chose ici, et on y reviendra.
Architecture mémoire : Memory Tree + vault Obsidian
L’idée centrale d’OpenHuman est le Memory Tree : une structure hiérarchique de résumés stockée dans SQLite localement. Toutes vos données connectées — emails, tickets, notes, documents — sont découpées en morceaux Markdown de 3 000 tokens maximum, scorés par pertinence et rangés dans cet arbre.
Ce qui distingue cette approche d’un RAG classique : au lieu d’une flat list de chunks vectorisés, les données sont organisées en niveaux de résumés imbriqués. Un nœud parent résume ses enfants. La fenêtre de contexte de l’agent charge d’abord les nœuds hauts, puis descend dans les sous-arbres pertinents. On peut ainsi injecter beaucoup plus de contexte utile avec moins de tokens bruts.
Les mêmes chunks sont aussi écrits comme fichiers .md dans un vault compatible Obsidian. Ce n’est pas un gadget : ça rend la mémoire de l’agent inspectable et modifiable directement par l’utilisateur. Si un résumé est faux, vous l’éditez dans Obsidian et la correction se propage.
Visualisation 1 — Pipeline Memory Tree :
Sources de données Auto-fetch (toutes les 20 min)
┌─────────────────┐ ┌──────────────────────────────┐
│ Gmail │──────────────▶│ │
│ Notion │──────────────▶│ Connecteur OAuth actif │
│ GitHub │──────────────▶│ → interroge chaque source │
│ Slack │──────────────▶│ → récupère données fraîches│
│ Calendar │──────────────▶│ │
│ Linear / Jira │──────────────▶└──────────────┬───────────────┘
│ Drive / Stripe │──────────────▶ │
└─────────────────┘ données brutes ▼
┌──────────────────────────────┐
│ TokenJuice │
│ HTML → Markdown │
│ suppression non-ASCII │
│ raccourcissement d'URL │
│ réduction jusqu'à 80% │
└──────────────┬───────────────┘
chunks ▼ ≤ 3k tokens
┌──────────────────────────────┐
│ Memory Tree (SQLite) │
│ ┌──── Résumé racine ─────┐ │
│ │ ┌── Résumé niveau 1 ─┐│ │
│ │ │ chunk · chunk · … ││ │
│ │ └────────────────────┘│ │
│ └────────────────────────┘ │
└──────────────┬───────────────┘
écriture miroir │ │ injection contexte
┌──────▼──┐ ▼
│ Vault │ Fenêtre de contexte
│Obsidian │ de l'agent LLM
│ .md │
└─────────┘
L’honnêteté s’impose : la qualité des résumés auto-générés dépend des appels LLM qui les produisent. En early beta, il peut y avoir des résumés approximatifs ou des chunks mal découpés. La possibilité d’éditer dans Obsidian est une vraie soupape de sécurité.
118+ intégrations OAuth avec auto-fetch
OpenHuman connecte les sources de données en un clic OAuth. La liste couvre Gmail, Notion, GitHub, Slack, Stripe, Google Calendar, Google Drive, Linear, Jira — et 109 autres. Pour chaque connexion active, le système interroge automatiquement la source toutes les 20 minutes et injecte les nouvelles données dans le Memory Tree.
Concrètement : si vous recevez un email de votre recruteur ou un commentaire sur une PR GitHub, l’agent en sera informé dans les 20 minutes sans que vous fassiez quoi que ce soit. La prochaine fois que vous lui posez une question contextuelle, ces données sont déjà dans l’arbre.
C’est ce qui rend l’approche différente des wrappers qui demandent à l’utilisateur de coller ses emails dans le chat. La persistance est automatique.
Ce qui reste à prouver en beta : la fiabilité des 118 intégrations est inégale. Les connecteurs majeurs (Gmail, GitHub) semblent stables. Les connecteurs moins courants sont probablement plus fragiles. Stripe comme source de données pour un agent personnel soulève aussi des questions légitimes sur ce qu’on injecte dans un LLM.
TokenJuice : compression intelligente avant le LLM
Chaque donnée qui entre dans le Memory Tree passe d’abord par TokenJuice, la couche de compression. Le principe : transformer les données brutes en forme la plus dense possible avant de les soumettre au modèle.
Les transformations appliquées :
- HTML → Markdown : suppression de tout le balisage superflu, conservation de la structure sémantique
- Raccourcissement d’URL : les URL longues sont remplacées par des formes courtes ou des références
- Suppression non-ASCII : caractères décoratifs, emoji répétés, séparateurs inutiles
- Condensation de whitespace : normalisation des espaces et sauts de ligne redondants
Le gain annoncé est jusqu’à 80% de réduction du volume tokenisé. Ce chiffre vient probablement de cas favorables (HTML de newsletter lourd), mais même 40-50% de réduction sur des données réelles aurait un impact direct sur les coûts d’API et la latence.
Pour un agent qui tourne en continu et injecte des données toutes les 20 minutes, cette compression n’est pas optionnelle — c’est ce qui rend le modèle économiquement viable sur le long terme.
Routage de modèles et pile d’outils
OpenHuman n’est pas lié à un seul LLM. Le routeur de modèles envoie chaque tâche au modèle le plus adapté :
| Type de tâche | Modèle cible |
|---|---|
| Raisonnement complexe, planification | Modèle de raisonnement (ex. o3, Claude Opus) |
| Réponses rapides, lookup | Modèle rapide (ex. GPT-4o-mini, Haiku) |
| Analyse d’images, captures d’écran | Modèle vision |
| Utilisation locale, offline | Ollama (Llama, Mistral, Gemma…) |
Le support Ollama mérite d’être souligné : toute la stack peut tourner entièrement en local, sans envoyer de données à des APIs tierces. Pour les données sensibles dans le Memory Tree (emails, tickets internes), c’est une garantie de confidentialité importante.
La boîte à outils intégrée couvre :
- Recherche web native
- Scraper web (avec compression TokenJuice en sortie)
- Outils coder complets : filesystem, git, lint, test, grep — une suite complète pour déléguer des tâches de développement à l’agent
- STT natif (speech-to-text) + TTS ElevenLabs pour les interactions vocales
La mascotte desktop avec lèvres synchronisées et réaction à l’environnement est la feature la plus visible — et probablement la plus clivante. Elle peut rejoindre un Google Meet comme participant réel, ce qui est techniquement remarquable et socialement… discutable selon les contextes. Ce n’est pas la partie centrale pour un usage ingénieur, mais ça montre l’ambition du projet.
Architecture système
┌──────────────────────────────────────────────────────────────────┐
│ Shell Desktop (Tauri / Rust) │
│ fenêtre native · tray icon · mascotte desktop │
└──────────────────────────────┬───────────────────────────────────┘
│
┌──────────────────────────────▼───────────────────────────────────┐
│ Interface Web │
│ chat · historique · configuration sources │
└───────────┬──────────────────────────────────┬───────────────────┘
│ │
┌───────────▼──────────────┐ ┌────────────▼──────────────────┐
│ Couche d'intégration │ │ Pile d'outils │
│ 118+ connecteurs OAuth │ │ web search · scraper │
│ auto-fetch 20 min │ │ filesystem · git · grep │
│ TokenJuice compression │ │ lint · test · STT/TTS │
└───────────┬──────────────┘ └────────────┬──────────────────┘
│ │
┌───────────▼──────────────────────────────────▼──────────────────┐
│ Moteur Mémoire │
│ ┌─────────────────────────┐ ┌──────────────────────────────┐ │
│ │ SQLite Memory Tree │ │ Vault Obsidian │ │
│ │ arbres de résumés │◀─▶│ fichiers .md synchronisés │ │
│ │ hiérarchiques │ │ éditables par l'utilisateur │ │
│ └────────────┬────────────┘ └──────────────────────────────┘ │
└───────────────┼─────────────────────────────────────────────────┘
│ contexte injecté
┌───────────────▼─────────────────────────────────────────────────┐
│ Routeur LLM │
│ raisonnement │ rapide │ vision │ local (Ollama) │
└───────────────┬─────────────────────────────────────────────────┘
│
▼
Réponse agent
L’architecture Rust/Tauri donne un binaire natif léger, avec des performances mémoire correctes et un packaging multi-plateforme propre. Le choix de SQLite pour le Memory Tree est pragmatique : pas de dépendance externe, requêtes rapides, fichier unique déplaçable. L’absence de vecteur-store séparé est un choix délibéré — la structure d’arbre remplace la recherche vectorielle par la navigation hiérarchique.
Installation et démarrage
L’installation est une seule commande. Pas de setup Docker, pas de configuration de dépendances externes.
macOS / Linux x64 :
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash
Windows :
irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex
Comme toujours avec les scripts d’installation en pipe : lisez le script avant de l’exécuter. C’est une bonne hygiène, particulièrement pour un outil qui va accéder à vos emails et tickets.
Après l’installation, le flux de démarrage est : lancer l’application, connecter une première source OAuth (Gmail ou GitHub sont les choix naturels), laisser le premier cycle d’indexation se terminer, puis commencer à interagir. Les premières réponses contextuelles arrivent après quelques minutes d’indexation, pas quelques heures.
Évaluation honnête : ce qui est rugueux, ce qui est prometteur
Ce qui fonctionne bien :
- Le concept Memory Tree est solide architecturalement. La distinction entre résumés hiérarchiques et flat-RAG est réelle et réduit le bruit dans la fenêtre de contexte.
- L’intégration Obsidian comme couche d’inspection est une décision de design intelligente. La mémoire reste sous contrôle de l’utilisateur.
- Le support Ollama pour un fonctionnement entièrement local est une vraie proposition de valeur pour les données sensibles.
- TokenJuice adresse un problème réel. La compression avant injection est souvent négligée dans les harnais agents.
Ce qui est encore rugueux :
- Early beta réel : des crashes et des comportements inattendus sont à prévoir. Ce n’est pas un outil de production pour des environnements critiques.
- Qualité des résumés auto-générés : le Memory Tree dépend de la qualité des appels LLM qui construisent les résumés. Des inexactitudes dans l’arbre se propagent dans toutes les réponses futures. L’édition Obsidian compense partiellement, mais demande de la vigilance.
- 118 intégrations ≠ 118 intégrations stables : les connecteurs majeurs semblent fonctionnels, les mineurs sont moins fiables. La liste impressionne sur le papier mais la qualité est inégale.
- Vie privée et LLMs cloud : si vous utilisez GPT-4 ou Claude comme routeur et que vos emails passent par TokenJuice avant d’atteindre l’API, vos données quittent votre machine. Le mode Ollama est la seule option vraiment privée.
- La mascotte : utile pour certains usages, dérangeante pour d’autres. Heureusement elle est probablement désactivable.
- Documentation : comme beaucoup de projets en early beta, la documentation n’a pas suivi le rythme du développement. Certaines features sont à découvrir par exploration.
Comparaison avec d’autres harnais agents
| Projet | Mémoire persistante | Intégrations auto-fetch | Stockage local | Desktop natif | Local LLM |
|---|---|---|---|---|---|
| OpenHuman | Memory Tree SQLite | 118+ OAuth, 20 min | SQLite + .md | Oui (Tauri) | Oui (Ollama) |
| Open Interpreter | Non (session) | Non | Non | Non | Oui |
| Letta (MemGPT) | Oui (mémoire externe) | Manuel | PostgreSQL | Non | Oui |
| Mem0 | Oui (vectoriel) | Partiel | Cloud / self-host | Non | Partiel |
| Obsidian Copilot | Via vault | Non | Local .md | Plugin | Oui |
| Aider | Non | Non | Non | Non | Oui |
OpenHuman occupe un espace assez spécifique : la combinaison d’un Memory Tree auto-alimenté, d’une interface desktop native et d’un support local complet. Letta est le concurrent le plus sérieux sur la mémoire persistante, mais cible davantage les développeurs qui construisent des agents, pas les utilisateurs qui veulent un assistant personnel.
Obsidian Copilot partage la philosophie du vault local mais reste un plugin sans intégrations automatiques. La comparaison la plus honnête : OpenHuman est ce que serait Obsidian Copilot si on lui ajoutait un fetch automatique de données externes et un routeur LLM.
Conclusion
OpenHuman est un pari architectural intéressant. L’idée de canoniser toutes vos données connectées dans un arbre de résumés local, mis à jour en continu et explorable via Obsidian, est plus ambitieuse et plus cohérente que la plupart des approches “RAG personnel” qui circulent.
Pour un ingénieur data ou IA qui cherche à expérimenter avec un assistant véritablement contextuel, c’est un projet qui mérite d’être installé et testé — avec des attentes calibrées pour une early beta. Ne l’utilisez pas pour des données critiques encore. Commencez avec des sources peu sensibles (GitHub, Calendar), vérifiez la qualité des résumés générés dans votre vault Obsidian, et évaluez si le Memory Tree ajoute vraiment de la valeur à vos sessions de travail.
Si le projet tient ses promesses sur les 6 prochains mois — stabilité des connecteurs, qualité des résumés, documentation — ce sera l’un des harnais agents personnels les plus complets disponibles en open source. Pour l’instant, c’est une idée solide dans un état de finition précoce.
Le dépôt : github.com/tinyhumansai/openhuman