GoClaw : une passerelle d'agents multi-locataires en Go, du binaire unique au poste de travail

Le problème visé : plusieurs utilisateurs, un seul déploiement

GoClaw se présente comme une passerelle d'agents IA multi-locataires écrite en Go. Le README énumère les briques attendues d'une plateforme de ce type : plus de 20 fournisseurs de modèles, 7 canaux de messagerie, PostgreSQL multi-locataire, le tout dans un binaire unique. La cible est donc l'équipe qui veut faire tourner des agents pour plusieurs personnes ou plusieurs espaces de travail sans dupliquer l'infrastructure à chaque fois. Le dépôt annonce des espaces de travail par utilisateur, des fichiers de contexte par utilisateur, des clés d'API chiffrées en AES-256-GCM, du RBAC et des sessions isolées. C'est un positionnement différent de celui d'un agent local pour un développeur seul : ici, l'unité d'intérêt n'est pas l'agent, c'est la frontière entre les locataires. Un point à garder en tête : le README parle d'OpenClaw comme du projet d'origine, mais le matériel fourni ne décrit pas OpenClaw, et rien n'indique ce qui a été repris, réécrit ou abandonné dans ce portage vers Go.

Le pipeline en 8 étapes et la mémoire en 3 niveaux

Le cœur du fonctionnement est décrit comme un pipeline en 8 étapes, dans cet ordre : context, history, prompt, think, act, observe, memory, summarize. Le README précise que les étapes sont branchables et que l'exécution est toujours active. Autrement dit, chaque tour de conversation traverse ces huit positions, et le point d'extension se situe au niveau de l'étape, pas du cycle complet. À cela s'ajoute un système de prompt à 4 modes (Full, Task, Minimal, None) avec filtrage par section et optimisation de la frontière de cache. Ce dernier détail compte : le fournisseur Anthropic est intégré en HTTP+SSE avec mise en cache de prompt, et la frontière de cache est un paramètre qui influence directement ce qui est facturé en entrée. La mémoire est organisée en trois niveaux : working (la conversation), episodic (les résumés de session) et semantic (un graphe de connaissances), avec un chargement progressif noté L0, L1, L2. Le graphe sémantique n'existe que dans l'édition serveur, pas dans Lite. Le README ne documente pas les seuils de bascule entre L0, L1 et L2, ni la politique de résumé : c'est une zone où il faudra lire le code ou la documentation hébergée sur docs.goclaw.sh.

Ce que le dépôt montre de l'orchestration

GoClaw ne se limite pas à un agent : il gère des équipes. Le README mentionne des tableaux de tâches partagés, de la délégation entre agents en mode synchrone ou asynchrone, et trois modes d'orchestration (auto, explicit, manual). L'édition desktop ajoute un tableau Kanban avec mises à jour en temps réel pour les tâches d'équipe. Il existe aussi un mécanisme d'auto-évolution décrit comme une chaîne métriques, suggestions, adaptation automatique, encadrée par des garde-fous, les agents affinant leur propre style de communication. C'est la partie la plus difficile à évaluer depuis l'extérieur : le README donne les noms des trois modes mais pas leur sémantique exacte, et on ne sait pas ce que les garde-fous bloquent concrètement. Un tableau de tâches partagé entre agents pose par ailleurs une question de concurrence que le choix de Go rend plausible à traiter, sans que le matériel fourni en démontre le comportement. À vérifier dans le code avant de confier une équipe d'agents à ce mécanisme.

Installation : deux chemins, deux bases de données

Il faut distinguer deux produits. L'édition desktop, appelée GoClaw Lite, s'installe par script. Sur macOS, le README donne curl -fsSL https://raw.githubusercontent.com/nextlevelbuilder/goclaw/main/scripts/install-lite.sh | bash. Sur Windows, la commande PowerShell équivalente est irm https://raw.githubusercontent.com/nextlevelbuilder/goclaw/main/scripts/install-lite.ps1 | iex. Lite embarque une base SQLite, une application native construite avec Wails v2 et React d'environ 30 Mo, et se met à jour depuis les publications GitHub. La compilation depuis les sources passe par make desktop-build, make desktop-dmg VERSION=0.1.0 pour un installeur macOS, ou make desktop-dev pour le rechargement à chaud, avec Go 1.26 ou plus, pnpm et la CLI Wails installée via go install github.com/wailsapp/wails/v2/cmd/wails@latest. L'édition serveur, elle, repose sur PostgreSQL 18 et Docker, et le README renvoie à une section Quick Start dont le matériel fourni ne contient que le mot Prere, tronqué. Les commandes exactes de démarrage du serveur ne sont donc pas vérifiables ici : il faut consulter docs.goclaw.sh/#quick-start. C'est une lacune du matériel, pas nécessairement du projet.

Lite contre Standard : le plafond est écrit noir sur blanc

Le README publie un tableau comparatif qui vaut mieux qu'un long argumentaire. Lite plafonne à 5 agents et à une seule équipe de 5 membres. Standard n'a pas de limite annoncée sur ces deux points. Lite utilise SQLite en local et une recherche textuelle FTS5 ; Standard utilise PostgreSQL et une recherche sémantique pgvector. Lite n'a aucun canal de messagerie, pas de graphe de connaissances, pas de RBAC ni de multi-locataire. Le versionnement est également séparé : les publications desktop utilisent des tags lite-v*, par exemple git tag lite-v0.1.0 && git push origin lite-v0.1.0, ce qui déclenche via GitHub Actions la construction d'un .dmg et d'un .tar.gz pour macOS et d'un .zip pour Windows. La conséquence pratique est simple. Si votre besoin est un agent unique sur votre machine, Lite suffit et évite Docker et PostgreSQL. Dès qu'il faut un canal Telegram ou Discord, un graphe de connaissances ou plusieurs utilisateurs, Lite est disqualifié par construction, pas par manque de configuration.

Sécurité annoncée et limites non documentées

Le README décrit une pile de sécurité en cinq couches comprenant un système de permissions, de la limitation de débit, de la détection d'injection de prompt, une protection SSRF et le chiffrement AES-256-GCM des clés d'API. Ces éléments sont nommés, pas détaillés : ni les règles de limitation, ni le taux de détection annoncé, ni la liste des motifs d'injection ne figurent dans le matériel fourni. La limitation la plus nette concerne la licence. Le badge du README indique CC BY-NC 4.0, une licence Creative Commons qui exclut l'usage commercial. L'API GitHub renvoie pourtant NOASSERTION, c'est-à-dire une licence non reconnue automatiquement. Les deux sources se contredisent, et une plateforme multi-locataires est précisément le genre de logiciel qu'une entreprise déploie pour rendre un service. Ce n'est pas un détail juridique à traiter après l'installation. Autre point de friction : les publications récentes sont des betas, v3.15.0-beta.208, .207 et .206 datées des 8 et 9 septembre 2026, soit plusieurs par jour. Une telle cadence indique un développement actif, mais aussi une surface mouvante pour qui épingle une version en production.

Face à une pile d'agents assemblée à la main

L'alternative la plus directe n'est pas un autre produit, c'est l'assemblage maison : un service Go ou Python qui appelle l'API du fournisseur, une base relationnelle pour l'historique, un bot par canal, et du code de glue entre les deux. La différence d'approche est nette. Dans un assemblage maison, l'isolation entre utilisateurs, le chiffrement des clés, la limitation de débit et la détection d'injection sont des problèmes que vous résolvez vous-même, un par un, et dont vous portez la maintenance. GoClaw les traite comme des couches du produit et les nomme dans son README. En contrepartie, un assemblage maison n'impose ni PostgreSQL, ni le pipeline en 8 étapes, ni le format de mémoire en trois niveaux : vous gardez la main sur chaque décision. GoClaw vous fait adopter son découpage, y compris ses étapes et ses modes de prompt. Le choix se joue donc sur un critère mesurable : combien de temps votre équipe passerait à réimplémenter l'isolation multi-locataire et le chiffrement des identifiants, comparé au temps passé à comprendre et à suivre le découpage de GoClaw.

Maintenance, mises à jour et coût de suivi

Le coût de maintenance se lit dans deux signaux du dépôt. Le premier est la branche par défaut, dev, et non main ou master : le travail atterrit d'abord sur dev, ce qui suggère un flux de développement continu plutôt qu'un cycle de publication figé. Le deuxième est la cadence des betas, plusieurs par jour sur la seule fenêtre du 8 au 9 septembre 2026. Suivre cette cadence demande soit d'épingler une version et d'accepter de prendre du retard, soit de tester régulièrement. L'édition desktop a son propre rythme, avec des tags lite-v* et une mise à jour automatique depuis les publications GitHub, ce qui signifie que la version installée peut changer sans intervention de votre part. Côté licence, le badge CC BY-NC 4.0 du README exclut l'usage commercial, tandis que l'API GitHub ne reconnaît pas la licence. Toute organisation qui envisage un déploiement en production doit faire trancher cette contradiction par sa propre analyse juridique, en se fondant sur le fichier LICENSE du dépôt plutôt que sur un badge.

Conclusion éditoriale

GoClaw convient aux équipes qui doivent héberger plusieurs utilisateurs ou plusieurs espaces de travail isolés sur un serveur unique, avec PostgreSQL comme socle et un binaire Go comme unité de déploiement. Il ne convient pas à qui veut un agent mono-utilisateur sans infrastructure : l'édition Lite existe pour ce cas, mais elle plafonne à 5 agents, une seule équipe et pas de canaux de messagerie. Avant d'adopter la version serveur, vérifiez trois points précis : la licence (le badge du README indique CC BY-NC 4.0, ce qui interdit l'usage commercial, alors que l'API GitHub renvoie NOASSERTION), les prérequis exacts de la section Quick Start, tronquée dans le matériel fourni, et la cadence des publications beta, qui atteint plusieurs versions par jour.

Sources officielles

1. Issues
2. nextlevelbuilder/goclaw on GitHub
3. Project website
4. README
5. Releases