OpenClaw et Imaginclaw résolvent le même problème — pourquoi importe-t-il où s'exécute le modèle ?
Ce sont deux passerelles personnelles pour agents IA connectant vos applications de messagerie (WhatsApp, Telegram, Slack, Discord...) à une IA capable d'agir réellement, et non de simplement répondre. Ce chevauchement est ce qui rend leur comparaison pertinente — il ne s'agit pas d'une promotion forcée.
Points communs
Les deux vont au-delà d'une simple boîte de chat. Les deux sont des passerelles auto-hébergées — vous gérez vous-même le processus, sans passer par un SaaS tiers. Les deux connectent les mêmes types de canaux à un agent IA capable de lire le contexte, d'utiliser des outils et d'agir en boucle, et non de répondre une seule fois.
OpenClaw
Un agent IA open-source viral — plus de 100 000 étoiles sur GitHub dès la première semaine, créé par le fondateur de PSPDFKit. Il est agnostique aux modèles : Claude, GPT-4o, Gemini ou un modèle local via Ollama fonctionnent indifféremment avec votre propre clé API. Il dispose d'accès au shell, au contrôle du navigateur et peut envoyer des e-mails en votre nom, en boucle, sans avoir à poser de question à chaque fois.
Imaginclaw
L'assistant souverain de Paulo, construit sur Hera — son runtime LLM local. Il s'exécute sur son propre matériel (deux GPU), avec des modèles locaux comme le chemin par défaut, et non en mode optionnel. Le cloud est un fallback délibéré et explicite, et non la base.
L'axe honnête
Quien contrôle le modèle et ce que vous résolvez réellement ? OpenClaw est open-source au sens de la licence — mais par défaut, vos messages et votre contexte transitent toujours par le cloud d'un tiers (Anthropic, OpenAI, Google), même si le gateway s'exécute sur votre machine. « Open-source » et « souverain » ne sont pas la même affirmation, et la documentation même d'OpenClaw le précise : il est model-agnostic PAR CONCEPTION, pas souverain par défaut.
Self-hosted décrit où réside le processus du gateway. Souverain décrit où vont vos données. OpenClaw résout le premier par conception ; Imaginclaw a été construit pour résoudre les deux.
La raison réelle pour laquelle cette comparaison vaut la peine
Imaginclaw n'a pas été conçu pour rivaliser fonction par fonction avec OpenClaw. Il a été développé car un gateway auto-hébergé qui route chaque message via l'API cloud d'un tiers ne résout pas réellement le problème de souveraineté : cela ne déplace que l'exécution du processus du gateway, pas la localisation de vos données. Si vous exécutez déjà des modèles locaux pour d'autres usages, l'application de ce même motif d'assistant dessus a été une décision cohérente, et non une innovation.