En 2026, l’agent de bureau quitte la « barre latérale de chat » pour devenir un collègue sur la durée. OpenHuman (open source chez TinyHumans) repose sur une boucle simple : d’abord synchroniser les données de vie, puis agir—branchez Gmail, calendriers, GitHub, Notion, Slack, etc., compressez la vie localement dans un Memory Tree de souvenirs Markdown lisibles, modifiables et supprimables, puis laissez l’agent bureau chercher, rédiger et exécuter des outils. Comparé à un nouvel onglet ChatGPT à chaque fois, on est plus proche d’un collègue qui se souvient de ce qui vous occupait la semaine dernière. Ci-dessous : architecture, articulation avec OpenClaw, et où placer la charge 24 h/24.
Du chat sans état au jumeau numérique
La plupart des LLM « oublient » à la fin du fil—quelques lignes de prompt système, ce sont des post-it. OpenHuman prend l’autre route : synchroniser d’abord les données de vie, puis agir. Parcours documenté (voir la documentation OpenHuman) : installation UI → comptes OAuth → auto-fetch environ toutes les vingt minutes → écriture dans le Memory Tree → miroir en vault Markdown compatible Obsidian, éditable ou raccourcissable à la main.
Ici, jumeau numérique IA personnel signifie données sur votre disque, lisibles par un humain, pas des fils opaques chez un éditeur. Projet en Beta, desktop d’abord, onboarding sans terminal annoncé ; la liste d’intégrations dans le dépôt GitHub fait foi.
Contrairement aux « super-apps » fermées, la GPL-3.0 autorise fork, politique de sync et répertoire mémoire modifiés, ou modèles locaux seuls hors ligne—pour les équipes qui refusent le lock-in mais veulent des non-dev branchés via l’UI. L’engouement GitHub / Product Hunt confirme le besoin de « second cerveau » ; cela ne vaut pas SLA entreprise ni conformité bouclée—pilotez avec des attentes réalistes.
Si vous avez déjà Obsidian, Logseq ou des notes de réunion, OpenHuman n’est pas « une app de notes de plus » mais « l’agent opère sur le vault que nous possédons déjà »—utile en achat : l’artefact reste des fichiers locaux, pas un historique de chat loué.
Memory Tree : la base de connaissance vit sur le disque
La communauté parle souvent d’OpenHuman comme d’un « agent à cerveau Obsidian », proche de l’idée LLM Knowledgebase de Karpathy : structurer des fragments en texte consultable et relu, plutôt qu’empiler l’historique de chat.
- SQLite en stockage canonique ; chunks Markdown alimentent des résumés en arbre pour ne pas injecter tout le vault dans le contexte ;
- dossiers ouverts dans Obsidian pour relecture, tags, suppression de passages sensibles ;
- outils memory / web-fetch / coder (git, lint, tests) et routage multi-modèles ; Ollama en option locale.
Pour les développeurs, fils d’issues, textes de PR et bouts de design doc deviennent un fond durable—sans recoller le même README à chaque session. Découpage et arbres de synthèse maîtrisent la longueur de contexte : « se souvenir plus » n’implique pas « brûler la fenêtre entière à chaque tour ».
Journée type : auto-fetch le matin pour mails et Slack ; l’après-midi le coder s’appuie sur des notes d’architecture dans le vault ; le soir la voix alimente les priorités du lendemain. Ouvrez le vault dans Obsidian : vous voyez ce que l’agent croit que vous savez—c’est l’écart fondamental avec le chat boîte noire.
Connexions et sync : raccourcir le cold start
La doc annonce de nombreuses intégrations (Gmail, GitHub, Slack, Notion, Linear, Drive, Stripe…) avec outils typés après OAuth ; des tirages périodiques visent « une sync et l’agent a vu boîte, agenda et dépôts », plutôt que deux semaines de copier-coller. Au-delà du texte : voix (STT/TTS) et coordination multi-agents—tâches légères sur modèles rapides, raisonnement lourd seulement si besoin.
Les entreprises doivent croiser DLP et « le corps complet des mails peut-il être stocké sur disque » ; côté perso : scopes OAuth minimaux, chiffrement disque—local d’abord n’est pas zéro risque. Si la politique interdit l’IA locale non approuvée sur les données pro, valider la sécurité avant les comptes bureau—c’est au niveau application et compte, pas du choix d’OS portable.
Déploiement qui tient la route : semaine 1 calendrier ou GitHub public ; semaine 2 mail après legal ; semaine 3 outils coder sur miroir de dépôt, pas clés de prod. Sauter ces étapes transforme vite « on a testé l’IA locale » en titre sur une fuite accidentelle.
Face à OpenClaw : se souvenir vs agir
| Dimension | OpenHuman | OpenClaw |
|---|---|---|
| Cœur | Memory Tree, mémoire lisible, jumeau bureau | Gateway, plugins, IM/Webhooks, souvent VPS Linux |
| Convient à | Second cerveau sur son propre disque—individus, petites équipes | Bots 24 h/24 et ingénieurs pilotés par pipelines |
| Exécution | Bureau ; veille / capot fermé arrête le travail | VPS/conteneurs adaptés aux callbacks Webhook |
| Forme de mémoire | SQLite + Markdown lisible | Sessions, canaux, config gateway |
Raccourci fréquent : OpenClaw fait « agir » l’agent, OpenHuman lui fait « savoir qui vous êtes ». Combinable—bot VPS pour l’extérieur, planification et mémoire longue dans un vault local, moins d’envie de poser toute la boîte mail perso sur un serveur public. Gateway sur VPS : HTTPS et GitHub Actions vs Docker manuel sur OpenClaw Gateway au standard production.
Confidentialité et limites opérationnelles
GNU GPL-3.0 permet fork et audit ; avec LLM cloud, les extraits tirés du Memory Tree franchissent encore des frontières—choisir la région modèle selon le contrat. Les jetons OAuth sont des clés : perte matérielle ou départ → revoke et relecture du vault. La doc évoque contrôle navigateur / machine—plus de droits, plus de surface pour erreurs et sur-collecte ; connexions test à faibles privilèges en environnement proche prod.
Ne comptez pas sur un portable fermé pour un bot Slack 24 h/24 : veille, coupures Wi‑Fi et mises à jour interrompent l’agent bureau ; webhooks externes → VPS ou conteneurs. En Beta : compte test « connecter → attendre un cycle fetch → ouvrir le vault et masquer », puis boîte principale ; supprimer à la main dans Obsidian les blocs obsolètes ou sensibles.
Auto-contrôle avant mise en service (8 points)
Pour responsables tech ou power users—plus de cases cochées = pilote justifié ; ce n’est pas un appel d’offres noté.
- Lassitude de réexpliquer le contexte projet à zéro ?
- Prêt à curater et supprimer la mémoire plutôt que tout déléguer au modèle ?
- Outils du quotidien dans la liste d’intégrations ou via plugin ?
- La conformité autorise-t-elle mail / métadonnées code sur PC perso ?
- Besoin encore de builds iOS / signature macOS ?—prévoir Mac en parallèle, pas dans le jumeau.
- Séparer Slack/Webhooks du jumeau bureau ?—OpenClaw cloud, OpenHuman local est plus clair.
- Accepter churn Beta et intégrations parfois cassées ?
- Changement machine / départ : export ou destruction du vault local prévus ?
Conclusion fréquente : OpenHuman d’abord pour la productivité perso, bots externes et livraison iOS via VPS ou Mac cloud—ne pas fusionner les trois lignes dans un seul achat.
Avec VPSSpark : jumeau en local, build et gateway dans le cloud
OpenHuman porte le jumeau numérique IA personnel—mémoire sur votre disque, lisible et supprimable. Archive xcodebuild, notarisation, TestFlight ou OpenClaw Gateway 24 h/24 pour Slack/Webhooks relèvent d’une île de build macOS licenciée et d’un VPS Linux toujours allumé—complémentaires, pas interchangeables.
Mac cloud Apple Silicon pour builds de nuit et files de signature ; VPS Linux pour gateways et automatisation—aucun ne remplace un vault Obsidian que vous entretenez, mais les deux découplent releases et canaux publics d’un portable qui dort.
Pilotez OpenHuman en local ; montez le 24 h/24 obligatoire dans le cloud—voir offres Mac cloud ou l’accueil VPSSpark pour choisir une région, valider un build propre ou un déploiement gateway, et caler mémoire, livraison et bots externes sur des rails séparés.