OpenHuman vs OpenClaw : quel est le véritable agent IA ?

En 2026, sur GitHub Trending, OpenHuman et OpenClaw reviennent souvent dans la même conversation — tous deux open source, tous deux se disent agents, tous deux tournent sur votre matériel. La question qui suit est naturelle : lequel est le véritable agent IA ? Formulation plus honnête : que signifie « agent » pour chaque projet ? Cet article n'est pas un match à élimination directe, mais une comparaison d'ingénierie des deux architectures — et comment les combiner sur Mac et Mac cloud.

La confusion est prévisible. Les deux visent les power users, promettent plus qu'une fenêtre de chat, et se self-hébergent. Chercher « le meilleur agent » sans lire les frontières produit mène à des déceptions : OpenHuman optimise le chemin des données brutes vers le contexte personnel ; OpenClaw optimise le chemin des messages et webhooks vers des commandes exécutables avec reçu. Cette différence structure l'architecture, l'exploitation et les mauvaises configurations typiques.

D'abord le vocabulaire : que veut dire « vrai agent » ?

Dans l'industrie, « agent » recouvre au moins trois niveaux : (1) une boucle LLM avec appels d'outils ; (2) mémoire persistante et sentiment d'identité ; (3) tâches multi-étapes cross-systèmes avec reçus auditables. Un seul échange ChatGPT ne satisfait qu'une partie de (1) ; les plugins Copilot approchent (1) et (2), mais le contexte reste souvent enfermé dans un SaaS unique.

OpenHuman construit l'agent comme jumeau numérique personnel : entrée desktop, Memory Tree, pull automatique 118+ SaaS — l'objectif est de « savoir qui vous êtes en quelques minutes ». OpenClaw le construit comme gateway self-hosted : un processus Gateway relie Telegram, Slack, WhatsApp, Discord et autres surfaces à des agents de code (comme Pi) ; l'accent est mis sur « un message depuis la poche, réponse avec chaîne d'outils ». Les deux sont des agents — mais le terrain par défaut diffère : desktop + données de workflow pour OpenHuman, canal + orchestration pour OpenClaw.

Pour un architecte, c'est structurant : OpenHuman ressemble à une usine de connaissance personnelle ; OpenClaw à une couche middleware agent-native. Confondre les deux, c'est attendre d'OpenClaw un pull Gmail automatique ou d'OpenHuman un déclencheur CI WhatsApp prêt à l'emploi — et échouer sur la mauvaise attente, pas sur le projet.

OpenHuman : agent personnel de type usine à contexte

Le pari central d'OpenHuman porte sur d'où vient le contexte, comment il est compressé et reste local. Le chemin officiel : connecter → pull auto → Memory Tree : Gmail, Notion, GitHub, Calendar et autres via OAuth, sync environ toutes les 20 minutes ; TokenJuice compresse mails HTML et sorties d'outils avant le LLM. La mémoire vit en SQLite local et Markdown compatible Obsidian — l'infrastructure du « me comprend ».

Les forces sont évidentes : cold start très rapide, UI-first, adapté aux non-utilisateurs de terminal. Les limites aussi : OpenHuman n'est pas un gateway multi-chat ; OAuth et routage de modèles dépendent encore par défaut du backend Tiny Humans — « local-first » n'équivaut pas à offline total. Analyse produit approfondie dans notre article sur le jumeau numérique OpenHuman.

Cas d'usage typiques : consultants avec de nombreuses sources d'information, product managers qui veulent un briefing matinal unifiant calendrier, issues et docs, ou développeurs solo fusionnant activité GitHub et notes personnelles. OpenHuman ne remplace pas votre IDE — il fournit le contexte transversal qu'un agent de code construirait lentement via plugins.

OpenClaw : gateway de canaux + orchestration d'ingénierie

La documentation OpenClaw définit clairement le projet comme Gateway sur votre machine : Discord, iMessage, Signal, Slack, Telegram, WhatsApp et autres surfaces sont reliés à des agents de code IA (ex. Pi). Licence MIT, Node 24+, openclaw onboard pour l'installation — utilisateurs typiques : développeurs et power users voulant piloter des assistants outillés depuis le mobile sans confier les données à un SaaS.

Dans le contexte ZavCloud, OpenClaw apparaît surtout côté orchestration d'ingénierie : ordre de déclenchement, commandes, codes de sortie et reçus structurés ; sur instance Mac mini cloud, il partage souvent runner GitHub Actions self-hosted et builds Xcode dans la même unité macOS auditable. Voir OpenClaw et CI Mac cloud. Le contexte OpenClaw grandit via plugins et sessions, pas via le pull OAuth massif d'OpenHuman — « connaît ma stack » demande ici plus de configuration et d'observation.

OpenClaw excelle quand le workflow est déjà centré sur la messagerie : statut de build dans Slack, retry manuel depuis Telegram, scripts de maintenance déclenchés par cron avec retour lisible. Il est plus faible quand le goulot d'étranglement est l'absence de contexte personnel agrégé sur des dizaines de SaaS.

Alors — qui est le « vrai » agent ?

Si « vrai » signifie détenir votre vie numérique en contexte — mails, documents, calendrier, activité code résumés automatiquement, éditables, consultables — OpenHuman se rapproche de cette définition. Il pousse l'agent hors de la fenêtre de chat vers une entrée desktop qui se souvient de vous.

Si « vrai » signifie réveillable partout, stable avec outils, écrivant les résultats dans les systèmes d'ingénierie — par exemple build depuis Telegram, SHA Git et code de sortie archivés — OpenClaw se rapproche de cette définition. C'est une couche de routage et d'orchestration agent-native, pas un produit de base de connaissances personnelle.

Le tableau comparatif officiel d'OpenHuman classe OpenClaw comme « terminal-first, dépendant des plugins, sans pull auto » — ce n'est pas une dépréciation, mais une déclaration de frontière produit. Inversement, les utilisateurs OpenClaw voulant une pipeline wiki Obsidian façon Karpathy doivent intégrer eux-mêmes ; les utilisateurs OpenHuman n'ont pas de CI WhatsApp clé en main.

En pratique, c'est rarement la philosophie qui tranche, mais le goulot : manque de visibilité matinale sur rendez-vous, mails et tâches → commencer par OpenHuman ; manque d'un canal fiable pour déclencher builds ou scripts depuis le chat d'équipe → commencer par OpenClaw. Beaucoup de setups productifs combinent les deux avec des responsabilités claires.

Trois scénarios de sélection typiques

• Développeur solo / consultant — beaucoup de mail et Notion, un twin desktop doit agréger le contexte → OpenHuman d'abord ; questions code occasionnelles depuis le mobile → Gateway OpenClaw en option.
• Petite équipe iOS / backend — GitHub Actions en place, relier runner et notifications à l'IM → OpenClaw + CI Mac cloud d'abord ; recherche documentaire personnelle en parallèle avec OpenHuman.
• Exigences compliance et audit élevées — les deux conviennent au self-hosting ; allowlist et isolation de canaux OpenClaw voir doc Security ; pour OpenHuman clarifier les limites Composio/OAuth, résumés sensibles via Ollama local si besoin.

Dans les équipes mixtes, une convention d'interface écrite aide : OpenHuman fournit un contexte structuré (ex. briefing quotidien en Markdown), OpenClaw consomme les déclencheurs et écrit les résultats en reçus par canal. Vous évitez ainsi une double source de vérité entre sync mail et bot chat.

Couche compute : pourquoi « vrai macOS » compte pour les deux

OpenHuman et OpenClaw supportent macOS, avec des besoins différents. OpenHuman tourne localement avec shell desktop et Memory Tree ; pour une sync continue en arrière-plan quand le portable reste fermé, une instance Mac mini cloud 7×24 est adaptée. Le Gateway OpenClaw vit souvent sur un serveur à sortie fixe : IPv4 statique pour webhooks, enregistrement runner et allowlists ; VNC utile pour le premier pairing de canal et le dépannage GUI.

Même principe que l'inférence Core ML sur la même machine : étaler les créneaux pour que sync, build et modèles locaux ne se disputent pas la mémoire unifiée. ZavCloud livre des unités M4 macOS physiquement exclusives — quel que soit le framework agent, le contrat compute peut rester identique.

Concrètement : sync OpenHuman la nuit et jobs légers, builds Xcode ou pipelines OpenClaw le jour — ou l'inverse selon fuseaux. L'essentiel est une séparation mesurable, pas le lancement aveugle de jobs lourds en parallèle sur une petite instance.

Un chemin minimal de validation pour chacun

OpenHuman : installer le DMG → connecter Gmail + Calendar + GitHub → attendre les premières entrées Markdown dans le Memory Tree → demander au desktop : « Quels rendez-vous aujourd'hui ? »

OpenClaw : installer le Gateway selon Getting Started → openclaw onboard → lier Telegram ou Web Control UI → envoyer depuis le mobile un message déclenchant des outils (ex. lire un fichier du dépôt).

Les deux parcours tiennent en moins d'une heure. Si OpenHuman échoue au callback OAuth, vérifier réseau et URLs de redirection ; si OpenClaw échoue au pairing canal, VNC sur l'instance cloud aide souvent mieux que SSH seul.

# Node 24+ requis (ou 22.19+ LTS)
npm install -g openclaw@latest
openclaw onboard --install-daemon
openclaw dashboard

# OpenHuman : macOS / Linux
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash

Conclusion : deux agents — pour deux « réalités » différentes

OpenHuman est usine à contexte + twin personnel — « vrai agent » ici : il se souvient de votre vie et travail au-delà des frontières SaaS. OpenClaw est gateway + orchestrateur — « vrai agent » ici : réveillable par canaux, routant sessions multi-agents et exécutant actions dans outils et pipelines. Plutôt qu'un vainqueur, tracer les frontières : OpenHuman pour la vie numérique personnelle, OpenClaw pour déclencheurs et reçus en équipe ; si le compute manque, processus permanents sur Mac mini cloud, machine locale en console seulement.

• OpenHuman — Jumeau numérique IA personnel en détail
• OpenClaw — Documentation officielle · Pratique CI Mac cloud
• Compute — ZavCloud instance Mac mini cloud