OpenClaw dispose d'une réimplémentation en Go : un binaire de 35 Mo au lieu de 800 Mo de dépendances

OpenClaw, qui a réuni environ 180 000 étoiles sur GitHub, dispose désormais d'une réimplémentation indépendante en Go. Le nouveau projet, baptisé GoClaw, promet de supprimer les principaux irritants de la version Node.js : dépendances lourdes, runtime superflu et déploiement compliqué sur des serveurs modestes.

À quoi sert GoClaw

Le principal reproche fait à OpenClaw ne concerne pas ses capacités, mais son packaging. Pour lancer le projet d'origine, il faut Node.js, npm, le dépôt lui-même et l'installation d'un vaste ensemble de dépendances, qui peut atteindre 500 à 800 Mo. Concrètement, cela se traduit par un premier lancement long, des conflits de versions, des problèmes avec les modules natifs et davantage de points de défaillance lorsqu'il faut déployer rapidement le service sur un VPS, un mini-PC ou un Raspberry Pi.

GoClaw règle le problème de la façon la plus directe : au lieu d'un écosystème de runtime et de node_modules, l'utilisateur obtient un unique binaire compilé statiquement d'environ 35 Mo. Il suffit de le télécharger, de lui donner les droits d'exécution et de l'utiliser. Pour des outils censés tourner en arrière-plan 24 h/24 et 7 j/7 en attendant des messages de Telegram, Discord ou d'autres canaux, ce format abaisse nettement le seuil d'entrée et simplifie la maintenance.

Comment le projet est conçu

GoClaw n'est ni un fork ni une fine surcouche de l'original, mais une version réécrite de zéro de la passerelle d'IA multi-agents. Le projet se connecte aux messageries, fonctionne avec plusieurs fournisseurs de LLM et mise sur la concurrence native de Go. L'article y voit une base plus naturelle pour des scénarios d'agents, où il y a beaucoup de requêtes parallèles, d'attentes de réponses d'API et de coordination entre rôles.

• Un seul binaire d'environ 35 Mo
• Prise en charge de plus de 11 fournisseurs de LLM
• Fonctionnement via 5 canaux de communication, dont Telegram et Discord
• Système multi-agents avec délégation et orchestration
• Tableau kanban pour gérer les tâches des agents

L'architecture s'articule autour de plusieurs agents spécialisés. L'un conçoit la solution, un autre écrit le code, un troisième vérifie les tests et un quatrième s'occupe de la relecture. Une tâche de haut niveau est décomposée automatiquement, puis les étapes sont réparties sur un tableau kanban interne. Pour Go, ce scénario paraît naturel : les goroutines et les canaux permettent de maintenir de nombreuses chaînes parallèles sans complexité superflue, alors qu'en Node.js tout cela repose généralement sur l'event loop et les promesses.

Gains et limites

GoClaw offre non seulement de la compacité, mais aussi une meilleure économie d'exploitation. Le document évoque une consommation de mémoire réduite de 3 à 5 fois par rapport à la version Node.js, à fonctionnalités comparables. C'est particulièrement important pour les VPS bon marché avec 512 Mo ou 1 Go de RAM, où chaque processus permanent engloutit vite les ressources. La conteneurisation y gagne aussi : une image d'application Go peut être construite presque à partir du seul binaire, alors qu'un service Node.js traîne généralement une base plus lourde et tout le répertoire de dépendances.

Mais cette transition a un prix. OpenClaw est fort non seulement par son code, mais par un écosystème mûr : une grande communauté, plus de 180K étoiles, des plugins éprouvés, des Skills et des intégrations. GoClaw est encore jeune, avec moins d'utilisateurs et moins de validation en production. Il n'y a presque pas de compatibilité entre les écosystèmes : les Skills existants d'OpenClaw ne peuvent pas simplement être repris et transférés.

Le choix dépend donc de la tâche : pour un service minimaliste tournant en arrière-plan, la version Go paraît logique ; si les plugins, la personnalisation et la communauté comptent, l'original reste pour l'instant nettement plus solide.

Ce que cela signifie

L'histoire de GoClaw illustre une tendance plus large : les outils d'IA sont de plus en plus jugés non seulement sur la qualité des modèles, mais aussi sur leur coût d'exploitation. Si un agent doit fonctionner de façon stable en arrière-plan, se déployer vite et ne pas exiger des centaines de mégaoctets de dépendances, Go devient un choix de plus en plus pratique.

Mais la victoire du langage n'est pas absolue : l'écosystème et la maturité du produit peuvent encore l'emporter sur la pure efficacité d'ingénierie.