En 2026, le récit côté agents ressemble souvent à ceci : après OpenClaw, on en a marre de réexpliquer chaque lundi pourquoi l’équipe a choisi l’option B. Des heures dans les skills, les prompts et les passerelles — puis la session se ferme et le contexte disparaît. OpenHuman revient sur GitHub Trending avec une promesse différente : moins d’enseignement manuel, une boucle de sync d’environ 20 minutes, tout l’essentiel dans une base locale.
Ce n’est pas un article sur les étoiles. On se concentre sur Connecter — Capturer — Mémoriser en Early Beta : Gmail, GitHub et calendrier avec des scopes minimaux, un arbre de mémoire (SQLite + export Obsidian) auditable, pas une boîte noire qui brûle des tokens. Pour cadrer le projet, voir OpenHuman sur GitHub Trending, c’est quoi ? sur Macstripe.
Les blogs tech francophones lisent souvent la chronologie ainsi : OpenClaw prouve que passerelle + skills marchent si vous investissez en ops ; OpenHuman pose la question inverse — est-ce que les faits SaaS personnels peuvent s’indexer sans copier-coller hebdomadaire dans le chat ? Les deux peuvent cohabiter sur le même Mac ; le titre « Après OpenClaw » rappelle d’abord la discipline gateway, puis la couche mémoire.
1. Ce qu’OpenClaw et Skills règlent — et ce qui reste ouvert
Après le buzz OpenClaw, beaucoup d’équipes utilisent encore deux voies où vous restez le formateur :
- Côté intégration : passerelle OpenClaw, skills ClawHub, webhooks et cron — excellent pour la messagerie et l’automation, mais installation de skills,
doctor, durcissement des droits. - Côté workflow : mattpocock/skills — discipline via
/grill-me,/tdd; vous maintenez CONTEXT.md et les règles du dépôt.
Point commun : Gmail, GitHub, Notion et calendrier ne fusionnent pas seuls en contexte personnel. La voie « base de connaissances personnelle » que Karpathy met en avant en 2026 — notes, mails et décisions code en Markdown requêtable — reste souvent manuelle dans ce duo.
OpenHuman vise la chaîne : OAuth → sync incrémentale ~20 min → compression dans un arbre de mémoire → routing modèle + retrieval au chat. Vérifiez les stars en direct sur GitHub ; le dépôt est en Early Beta, procédures selon le GitBook officiel.
2. Fond technique : arbre de mémoire et base « façon Karpathy »
OpenHuman n’est pas un RAG cosmétique. Dans la doc publique, trois niveaux (libellés selon version) :
- Arbre sources : incréments bruts par connecteur (Gmail, GitHub…).
- Arbre thématique : résumés par projet, personne, chronologie.
- Index global : navigation inter-thèmes pour l’agent.
Source de vérité : SQLite local ; en parallèle, fragments .md compatibles Obsidian (souvent ≤3000 tokens par segment) pour relecture humaine. Avant le dialogue, des mécanismes type TokenJuice compressent les passages pertinents — pas un pourcentage fixe garanti, mais moins d’« historique entier dans le prompt ».
Le Model Routing choisit raisonnement, rapidité ou vision ; hors ligne, Ollama ou MLX sur Mac. OpenClaw/Skills = orchestration et discipline ; OpenHuman = souvenirs personnels multi-sources.
Pour la conformité : données par défaut en local, connecteurs révocables, exports lisibles. Cela ne remplace pas une AIPD, mais déplace le débat de « tout dans le cloud du chat » vers « quels scopes OAuth avons-nous réellement accordés ». Documentez par connecteur finalité, rétention et suppression — comme pour une passerelle OpenClaw self-hostée.
3. Tableau : OpenClaw/Skills vs OpenHuman « Connecter–Capturer–Mémoriser »
| Dimension | OpenClaw / Skills / Rules | OpenHuman |
|---|---|---|
| Qui entretient « me connaît » | Vous : prompt, skill, CONTEXT.md | Sync arrière-plan + index (vous auditez l’export Obsidian) |
| Tiers | clés/webhooks par plateforme | doc : 118+ services OAuth (console = référence) |
| Rafraîchissement | manuel ou cron maison | ~20 min de polling sur comptes connectés |
| Sur plusieurs semaines | docs repo + mémoire persistante | retrieval de contexte personnel inter-sessions |
| Coût typique | ops passerelle, versions skills, droits | stabilité beta, GPL-3.0, audit connecteurs |
En bref : OpenClaw vous fait coach ; OpenHuman veut lire votre journal numérique — avec erreurs possibles, d’où SQLite + Markdown pour vérifier, corriger, supprimer.
En revue produit, ce tableau sert de matrice : automation messagerie (→ OpenClaw), rituels code en dépôt (→ Skills), carte vie/travail SaaS (→ OpenHuman) ? Souvent « les trois » — alors l’ordre d’adoption compte plus que le nombre d’outils : une couche stable, puis la suivante.
4. Workflow : que faire dans un cycle de 20 minutes
20 minutes = rythme de sync, pas « omniscient 1200 secondes après install ». Première mise en route :
4.1 Connecter : jeu minimal de connecteurs
Après les Releases, pas 118 OAuth d’un coup. Recommandé :
- une boîte mail (Gmail pro ou alias, pas les deux) ;
- une source code (compte perso GitHub ou une org) ;
- un calendrier (Google ou Outlook) ;
- optionnel Notion ou Drive — pas de doublon documentaire.
Par source : lecture seule vs écriture, révocation, PII. Mail entreprise après validation sécurité.
4.2 Capturer : attendre 1–2 cycles
Une fois connecté, le moteur tire les incréments (~20 min par défaut) : sujets mail, commits, changements d’agenda. À ce stade :
- vérifier « dernière sync » et connecteurs en échec ;
- croissance disque (index + .md) vs attente ;
- ne pas juger avec « il connaît déjà ma réunion d’hier » — d’abord la santé du pipeline.
4.3 Mémoriser : arbre et audit Obsidian
Erreur fréquente en beta : poser tout de suite une question de planification complexe. Mieux un test en deux temps — (A) fait mono-source (« dernier commit sur repo X »), (B) corrélation (« commit X + réunion Y au calendrier »). Si A échoue, pipeline cassé ; si seulement B, plutôt arbre thématique ou qualité des résumés. Gardez les réponses datées dans openhuman-audit/ pour voir les régressions après mise à jour.
Ouvrez le chemin Obsidian du setup, échantillonnez 3–5 .md auto :
- titres alignés sur événements réels (PR, fil mail) ?
- promo classée à tort en « décision projet » ?
- tokens/secrets en clair ? → couper le connecteur, ouvrir une issue.
Puis une question multi-sources et vérifiez que les citations pointent vers les bons fragments md.
4.4 En parallèle avec OpenClaw et Skills (topologie conseillée)
[Gmail/GitHub/Calendrier …] --OAuth--> Arbre OpenHuman (SQLite + .md)
|
v
Routing modèle (cloud / Ollama / MLX)
^
[Cursor + mattpocock/skills] ---- code ----+
[Passerelle OpenClaw] ---- IM/Webhook/Cron --+Pas deux « vérités projet » désynchronisées : contexte personnel cross-outils → OpenHuman ; décisions dépôt → CONTEXT.md / ADR versionnés.
4.5 Quand s’arrêter ou revenir en arrière
- retrieval confus, résumés Obsidian médiocres → réduire connecteurs, pas grossir le modèle ;
- copyleft GPL bloque produit propriétaire → pas d’intégration profonde ;
- besoin surtout d’un bot Telegram 24×7 → prioriser déploiement OpenClaw sur Mac distant.
5. Questions fréquentes
« 20 minutes et c’est réglé », marketing ?
Plus juste : sync automatique toutes les ~20 minutes. « Tout comprendre » dépend des sources, de l’historique et de votre relecture des exports. Voyez un ETL personnel auditable, pas de la télépathie.
Conflit avec une base Karpathy manuelle ?
Non. OpenHuman automatise les faits SaaS ; dans Obsidian restent jugement, priorité et conclusions type ADR. Machine = ce qui s’est passé ; humain = ce qu’on a choisi.
Facture tokens qui explose ?
Routing + compression envoient plutôt des fragments utiles — mais beaucoup de sources bruyantes (chats, alertes) gonflent index et retrieval. Une semaine en connecteurs minimaux, puis facture et disque.
Remplacer OpenClaw ?
Non. OpenClaw = passerelle et canaux ; OpenHuman = ingestion personnelle. Les deux peuvent partager la même API d’inférence locale sur un Mac avec beaucoup de RAM.
GPL-3.0 et outil interne ?
Embedding commercial propriétaire → avis juridique. Usage perso ou labo interne souvent OK ; white-label assistant souvent bloqué — anticipez avant d’activer 118 connecteurs en prod.
6. Où mettre le calcul : portable, bureau, Mac distant
Index et arbre vivent sur disque local ; les gros modèles peuvent tourner sur Apple Silicon ou un Mac distant à forte RAM — portable pour l’UI seulement. Pour sync 24×7 + passerelle, un nœud macOS dédié évite les coupures quand le lid se ferme — aligné avec la topologie Macstripe « agent dans le cloud, sortie de données maîtrisée ».
Conseil terrain : UI et clients légers sur le portable ; ollama serve ou MLX sur un Mac 24 Go+ unifié en datacenter. Même habitude SSH/VNC que pour les runners CI, mais orientée agent.
Pour regrouper OpenHuman et OpenClaw sur un Mac Mini M4, voir nœuds et réservation sur l’accueil Macstripe.
7. Conclusion
L’ère OpenClaw montre que les ingénieurs aiment enseigner l’IA — mais pas deux fois la même semaine. Le récit OpenHuman, c’est la base Karpathy en pipeline interrogeable, compressible, exportable localement — Connecter, Capturer, Mémoriser ; 20 minutes, c’est le tempo, pas la magie.
- OAuth minimal, 1–2 cycles, puis tester le retrieval.
- export Obsidian comme check-up mémoire ; en cas d’erreur, couper la source ou ajuster les droits.
- Skills / OpenClaw : contexte perso vs discipline dépôt vs messagerie.
Early Beta = projet d’audit, pas secrétaire de prod. Approfondir : c’est quoi OpenHuman ? ; mémoire sur plusieurs semaines : pourquoi Cursor « oublie ».
