ClaraVerse : un espace de travail IA auto-hébergé qui parie sur les agents en équipe

Le problème visé : recoller cinq outils derrière une seule interface privée

La plupart des interfaces de chat pour modèles locaux traitent la mémoire et les agents comme des ajouts tardifs. ClaraVerse part du principe inverse : le README annonce un espace de travail construit autour de trois éléments, des agents qui fonctionnent comme une équipe, une mémoire à paliers, et une licence qui ne se met pas à facturer quand le projet devient visible. Le projet se présente comme un remplacement de ChatGPT, Claude, N8N et de la génération d'images, avec vos propres clés et votre propre calcul. La cible est donc l'équipe technique qui possède déjà un serveur, un Ollama ou un LM Studio, et qui ne veut pas que ses conversations partent chez un fournisseur. Le dépôt est en TypeScript, la branche par défaut est main, et les trois dernières versions publiées (v0.2.0, v0.3.0, v0.3.1) datent toutes du 31 mai 2026, avec v0.3.1 présentée comme une installation RAG en une ligne. Cette cadence serrée sur une seule journée mérite d'être notée : elle suggère des correctifs rapprochés plutôt qu'un cycle de publication étalé.

Crew : une file de cartes avec relecture humaine

Crew est le mécanisme le plus distinctif du projet. Le README décrit le flux ainsi : vous donnez un brief à un projet, vous engagez une équipe d'agents, puis vous travaillez la file de cartes. Chaque carte revient pour validation avant d'être livrée. Le projet insiste sur le fait qu'il n'y a pas de boîte noire, ce qui revient à dire que la supervision humaine est un point d'étape obligatoire et non une option. C'est un choix de conception qui a un coût : tant qu'une carte attend votre relecture, elle ne progresse pas. Pour un usage exploratoire, cette file peut devenir un goulot d'étranglement si personne n'est disponible pour valider. Le README ne détaille pas le format d'une carte, ni la façon dont les agents se répartissent le travail, ni la politique de reprise après échec. Ce sont des zones que la documentation laisse dans le flou, et il faut les tester soi-même avant de confier à Crew une tâche dont dépend une échéance.

La mémoire à deux paliers, et la décroissance qui va avec

La mémoire de ClaraVerse est structurée en paliers. Le palier pinned contient les faits marqués comme toujours injectés (allergies, contraintes dures, la façon dont vous voulez être appelé). Ces entrées échappent au calcul de pertinence et ne décroissent jamais. Le palier recall contient le reste, récupéré par similarité d'embedding avec la conversation en cours, donc seuls les éléments pertinents sont injectés. Les souvenirs inutilisés perdent de la pertinence avec le temps et s'archivent automatiquement. Le modèle pilote lui-même ce mécanisme : il appelle search_memory et add_memory en cours de conversation, comme n'importe quel autre outil. Le stockage est chiffré au repos en AES-256-GCM, avec une clé dérivée par utilisateur via HKDF, et le README affirme qu'un administrateur ClaraVerse ne peut pas lire vos souvenirs. La décroissance est le point le plus discutable : un fait rarement sollicité mais important peut s'archiver sans que vous l'ayez demandé, et le README ne précise pas de seuil ni de durée avant archivage. Le palier pinned est justement là pour contourner ce risque, mais il n'est utile que si vous savez à l'avance quels faits sont critiques.

Installation : deux chemins, dont un incomplet pour le RAG

Le chemin le plus court est une ligne de commande : curl -fsSL https://raw.githubusercontent.com/claraverse-space/ClaraVerse/main/cli/install.sh | bash && claraverse init. Le chemin Docker Compose consiste à cloner le dépôt, entrer dans ClaraVerse, puis lancer docker compose -f docker-compose.production.yml up -d, avant d'ouvrir http://localhost:3000, de créer le compte, le premier utilisateur devenant administrateur. Une variante docker run existe avec les volumes claraverse-data et claraverse-uploads et l'option --add-host=host.docker.internal:host-gateway. Le README est explicite sur une limite de cette variante : le conteneur unique démarre, mais l'onglet Knowledge et l'outil search_knowledge ont besoin des sidecars, et sans eux l'application renvoie embeddings service unreachable. Il faut donc la pile Compose complète avec MySQL, MongoDB, Redis, SearXNG, Qdrant et le sidecar d'embeddings pour que le RAG fonctionne. Deux variables d'environnement sont documentées : CLARAVERSE_PORT (3000 par défaut) et OLLAMA_BASE_URL, plus LMSTUDIO_BASE_URL. Côté Ollama, le piège classique est rappelé : Ollama écoute sur 127.0.0.1 par défaut, adresse injoignable depuis un conteneur, il faut donc définir OLLAMA_HOST=0.0.0.0. La détection des fournisseurs locaux tourne toutes les deux minutes, désactive un fournisseur hors ligne et réimporte ses modèles à son retour.

Un terminal en plus du navigateur, avec un chemin d'installation distinct

Clara Agent est livré dans le même dépôt et se présente comme un agent de codage qui lit, écrit et modifie des fichiers et exécute des commandes sur votre machine, avec le même modèle et le même compte que l'application web. L'installation se fait par claraverse agent install, qui construit l'agent et place claracli dans le PATH, puis il faut lancer /login claraverse pour connecter le terminal. Ce point compte pour évaluer la surface de risque : un agent qui exécute des commandes sur votre machine n'a pas les mêmes conséquences qu'un chat dans un onglet. Le README ne décrit ni les garde-fous d'exécution, ni la confirmation avant commande. C'est une lacune documentaire à combler par la lecture du code de clara-agent/ avant de laisser l'outil opérer sur un dépôt de production.

Licence : AGPL-3.0 affichée, NOASSERTION dans le dépôt

Le badge du README indique AGPL-3.0 et renvoie vers le fichier LICENSE, et l'argument de vente du projet repose en partie sur cette licence, présentée comme un garde-fou qui ne se met pas à facturer quand le projet devient populaire. Mais les métadonnées du dépôt listent la licence comme NOASSERTION, ce qui signifie que l'outil d'analyse n'a pas su rattacher le fichier à une licence reconnue. L'écart peut venir d'un texte de licence modifié, d'un fichier mal formé, ou d'une licence composite. Tant que ce point n'est pas tranché, personne ne devrait fonder une décision commerciale sur le badge. L'AGPL-3.0, si elle s'applique bien, impose de fournir le code source aux utilisateurs d'un service modifié accessible par réseau, ce qui exclut la revente en produit fermé. Ce paragraphe n'est pas un avis juridique : faites lire le fichier LICENSE par quelqu'un dont c'est le métier.

Face à Open WebUI : le même socle, une autre ambition

Le README consacre une section à la comparaison avec Open WebUI, ce qui donne un point de repère utile. Open WebUI est une interface de chat pour modèles locaux, et son périmètre s'arrête largement là. ClaraVerse ajoute par-dessus le même type de socle deux briques que Open WebUI ne revendique pas : les équipes d'agents avec file de cartes et relecture, et une mémoire à paliers avec décroissance et chiffrement par utilisateur. En contrepartie, ClaraVerse demande une pile plus lourde, avec Qdrant et le sidecar d'embeddings pour que la base de connaissances fonctionne, là où une installation Open WebUI se contente d'un service et d'un modèle. Le choix se joue donc sur ce que vous voulez administrer. Si vous voulez seulement parler à un modèle local depuis un navigateur, la pile ClaraVerse est surdimensionnée. Si vous voulez que l'assistant se souvienne et que plusieurs agents travaillent un brief, la comparaison change de nature.

Coût de maintenance et pièges de mise à jour

Le README documente trois commandes de maintenance : docker compose -f docker-compose.production.yml logs -f claraverse pour les journaux, la même avec restart pour redémarrer, et down -v suivi de up -d pour repartir de zéro. Cette dernière commande supprime toutes les données, volumes compris, et le README le signale explicitement. La pile Compose embarque MySQL, MongoDB, Redis, SearXNG, Qdrant et un sidecar d'embeddings : ce sont autant de composants à mettre à jour séparément, et une montée de version de Qdrant ou du sidecar peut casser l'onglet Knowledge sans que le conteneur principal échoue. Les trois versions publiées le même jour suggèrent des correctifs rapprochés, donc prévoyez de suivre les tags plutôt que de rester sur latest. La variable CLARAVERSE_PORT permet de déplacer l'interface, mais le README ne décrit aucune procédure de sauvegarde des volumes claraverse-data et claraverse-uploads, ce qui laisse la restauration entièrement à votre charge.

Conclusion éditoriale

ClaraVerse convient aux équipes qui veulent un chat, une base de connaissances RAG et des agents multi-modèles sur leur propre matériel, avec la licence AGPL-3.0 comme garde-fou contre la revente fermée. Il ne convient pas à qui refuse d'administrer MySQL, MongoDB, Redis, SearXNG et Qdrant, ni à qui a besoin d'une licence permissive. Avant d'adopter, vérifiez le fichier LICENSE réel, testez la pile complète avec docker compose -f docker-compose.production.yml, et confirmez que OLLAMA_HOST=0.0.0.0 est bien positionné côté hôte pour que la détection automatique fonctionne.

Sources officielles

1. claraverse-space/ClaraVerse on GitHub
2. Issues
3. Project website
4. README
5. Releases