OpenLoomi est un assistant IA open source qui veut devenir la mémoire de travail de vos agents, de vos messages et de vos projets. Après un vrai test local, mon verdict est simple : l’idée est solide et utile, mais le produit reste jeune, avec une installation qui demande encore des nerfs de DevOps.
OpenLoomi, c’est quoi ?
OpenLoomi se présente comme une alternative open source à un coworker IA façon Claude, avec un angle précis : donner de la mémoire aux agents. Pas seulement un chat avec historique, mais un espace qui agrège documents, messages, décisions, tâches, connecteurs et souvenirs locaux.
Dans le README, le projet parle de “Holistic Context”. En pratique, cela veut dire : avant qu’un agent réponde ou agisse, il peut retrouver ce qui a déjà été décidé, qui a dit quoi, quel projet est lié, et quelles actions restent ouvertes.
C’est exactement le genre de brique qui manque souvent dans les stacks d’agents. On a des LLM, des outils, des crons, des connecteurs, mais la mémoire opérationnelle finit vite en bazar.
Installation de OpenLoomi
J’ai cloné le dépôt GitHub dans /tmp, puis lancé l’installation depuis une copie de travail temporaire, avec Node, pnpm, SQLite local et le proxy LLM fourni.
La doc développeur annonce :
git clone https://github.com/melandlabs/openloomi.git
cd openloomi
cp apps/web/.env.example apps/web/.env
pnpm install
pnpm tauri:dev
Dans mon environnement de test, je n’ai pas lancé l’application desktop Tauri complète, faute de Rust installé dans le conteneur. J’ai donc testé la partie web Next.js, les migrations SQLite et le skill de mémoire locale. C’est une limite du test, mais ce n’est pas un simple smoke test : j’ai installé les dépendances, démarré l’app, obtenu une réponse HTTP 200 et fait produire une mémoire consultable par OpenLoomi.
| Élément | Résultat observé |
|---|---|
| Version repo | 0.6.1 |
| Stack visible | Next.js 16, React 19, pnpm monorepo, SQLite, Tauri |
| Installation | 2170 paquets installés |
| Base locale | SQLite initialisée, migrations appliquées |
| Web app | Page / servie en HTTP 200 |
| LLM proxy | Configuré, mais la route API chat a bloqué au test |
| Correctifs nécessaires | katex, pino, sanitize-html, turndown ajoutés dans l’environnement de test |
OpenLoomi à l’usage
Mon cas d’usage était volontairement concret : simuler une mémoire de travail DevOps avec deux informations.
La première note concernait Jarvis, un assistant interne qui doit garder les décisions et incidents. La seconde concernait un client fictif ACME avec une décision de migration de reverse proxy.
J’ai utilisé le skill openloomi-memory, fourni dans le dépôt, pour écrire puis rechercher ces informations dans une mémoire locale sous ~/.openloomi/data/memory/.
node skills/openloomi-memory/scripts/openloomi-memory.cjs add-memory \
"Projet Jarvis: tester OpenLoomi pour garder les décisions DevOps" \
--file=jarvis-openloomi.md --directory=projects
node skills/openloomi-memory/scripts/openloomi-memory.cjs search-memory "reverse proxy"
Résultat réel : OpenLoomi a créé les fichiers mémoire, puis a retrouvé la décision ACME et la note Jarvis avec le chemin, la ligne et un extrait. C’est basique, mais c’est propre, lisible, et surtout auditable. Pour un profil sécu ou DevOps, c’est un bon point : on peut voir où est la donnée.
Ce que j’aime dans OpenLoomi
Le premier bon point, c’est l’orientation local first. La mémoire fichier, SQLite et les skills lisibles donnent une impression saine : on n’est pas face à une boîte noire SaaS qui aspire tout.
J’aime aussi la vision produit. OpenLoomi ne vend pas juste “un agent de plus”. Il essaie de résoudre un vrai problème : comment donner du contexte stable à des agents qui travaillent sur des projets longs.
Autre point intéressant : les skills inclus. Le dépôt contient des skills pour la mémoire, les connecteurs, l’API, les documents, les présentations et d’autres usages. Pour un freelance ou une petite équipe, cela peut devenir une bibliothèque d’actions réutilisables.
Enfin, le produit expose clairement ses ambitions connecteurs : Gmail, Calendar, Telegram, WhatsApp, Slack, Discord, Jira, Notion, RSS et plus. Je n’ai pas branché ces services avec de vraies clés, mais l’architecture montre bien où le projet veut aller.
Les limites de OpenLoomi
La limite principale, aujourd’hui, c’est la maturité d’installation. Sur mon test, l’installation pnpm s’est faite, mais le démarrage web a révélé plusieurs dépendances non résolues : katex, pino, sanitize-html, turndown. Après ajout dans l’environnement de test, la page web a fini par répondre.
Autre point : le démarrage Next.js est lourd. La première compilation a pris longtemps, avec beaucoup de logs. Ce n’est pas choquant pour un gros monorepo, mais ce n’est pas encore l’expérience “je clone et ça tourne” que j’attends d’un outil grand public.
La route OpenAI compatible /api/ai/v1/chat/completions a été configurée avec le proxy local demandé. Elle a bien commencé à compiler, mais la requête de test est restée bloquée jusqu’au timeout. Je ne vais donc pas prétendre que le chat LLM fonctionne en bout en bout dans mon environnement.
Dernier point : l’app desktop Tauri semble être le chemin utilisateur principal. Sans Rust dans le conteneur, je n’ai pas validé le paquet desktop complet.
Est-ce que OpenLoomi marche vraiment ?
Oui, partiellement, et c’est important de le dire précisément.
Ce qui a marché : l’installation du monorepo, le démarrage de la web app, l’initialisation SQLite, les migrations, la page HTTP 200, et le skill de mémoire locale qui produit des fichiers puis les retrouve.
Ce qui n’a pas marché complètement : le flux LLM via l’API chat dans mon test, et le desktop Tauri complet. Pour moi, OpenLoomi est donc exploitable comme brique de mémoire locale et comme base technique à explorer, pas encore comme produit que je donnerais sans accompagnement à un client non technique.
Faut-il adopter OpenLoomi ?
Mon verdict : essayer, mais ne pas adopter en production sans garde fou.
OpenLoomi vaut le détour si vous construisez des agents, un assistant interne, une mémoire de projet, ou un poste de travail IA local. Pour un freelance sécu ou DevOps, l’idée de garder les décisions et preuves dans des fichiers locaux, puis de les rendre cherchables par un agent, est très pertinente.
En revanche, si vous cherchez une app prête pour un utilisateur final, avec install sans friction et connecteurs tous validés, attendez encore. Le projet avance vite, mais il a encore des aspérités de monorepo jeune.
Je le classerais dans la catégorie : “à surveiller et à prototyper”. Pas du hypeware, pas encore un outil plug and play, mais une vraie piste pour donner une mémoire durable aux agents.
FAQ
OpenLoomi est-il vraiment open source ?
Oui, le dépôt est public sur GitHub et sous licence Apache 2.0. Le code, les skills et la structure de l’app sont inspectables.
OpenLoomi peut-il tourner sans clé OpenAI ?
Une partie oui, notamment la mémoire locale. Pour les fonctions IA, il faut configurer un fournisseur compatible OpenAI ou OpenRouter, ou un proxy local comme dans mon test.
OpenLoomi est-il prêt pour un usage non technique ?
Pas encore selon mon test. Le concept est prometteur, mais l’installation et certains chemins API demandent encore des compétences de debug Node, SQLite et environnement local.