Vous connaissez déjà la routine : le matin, vous réexpliquez à ChatGPT que vous faites de l’outsourcing iOS ; l’après-midi, un fil Slack vous oblige à tout redire. Notion contient pourtant les contraintes client, et le mail les redemande. À l’ère des agents, les outils se multiplient, mais le contexte reste morcelé. OpenHuman (projet open source) tente de traiter ce second problème : relier Gmail, Notion, GitHub, le calendrier, etc. à une bibliothèque de mémoire locale, pour que l’assistant cite « ce que vous avez promis la semaine dernière » ou « le deadline modifié dans le mail client » sans repartir de zéro.
Dépôt : tinyhumansai/openhuman. Client desktop macOS / Windows / Linux. Documentation : GitBook OpenHuman (dont auto-fetch). Ce texte n’est pas un tutoriel d’installation : c’est un guide de décision d’hébergement pour ceux qui comptent l’utiliser sérieusement — machine locale ou Mac mini cloud dédié, articulation avec OpenClaw sur Mac distant, et quand la location cloud mac vaut mieux qu’un portable qui dort au fermeture du capot. Week-end de test sur MacBook : OK. Pour un auto-fetch 7×24, une sortie OAuth stable et un disque extensible, continuez.
1. Ce que fait OpenHuman : pipeline mémoire, pas un copilote de plus
OpenHuman se présente comme un système IA personnel sur desktop : noyau Rust, interface TypeScript, OAuth en un clic (les communications publiques évoquent 118+ intégrations). Le pari produit n’est pas « un modèle plus malin » mais un pipeline de données persistant. Le Memory Tree compresse mails, agenda, documents et activité code en Markdown, puis stocke dans SQLite et un dépôt local type Obsidian — la doc parle d’un wiki style Obsidian.
Par défaut, l’auto-fetch tourne environ toutes les 20 minutes : nouveaux mails, changements calendrier, commits sont rapatriés et indexés. En pratique, l’assistant peut répondre à « qu’ai-je promis à ce client hier ? » ou « qui a mergé le PR bloquant cette semaine ? » — si l’hôte reste éveillé, le réseau tient, et le disque ne se remplit pas en silence.
Face à un Copilot qui répond à la question du moment, OpenHuman ressemble plutôt à un ETL privé + couche agent sur votre matériel. Vous échangez la commodité cloud contre rétention locale et connecteurs larges — ce qui ne vaut le coup que si la machine qui tourne est fiable.
| Capacité | Approche OpenHuman | Impact hébergement |
|---|---|---|
| Intégrations | OAuth Gmail / Notion / GitHub, calendriers… | Moins de clés API ; plus de charge sync en arrière-plan |
| Mémoire | Memory Tree + vault Markdown | Recherche transversale ; disque rapide et sauvegardes |
| Sync | auto-fetch planifié (~20 min) | Récompense un Mac toujours allumé ; punit sommeil et Wi‑Fi instable |
| Privacy | Données en local par défaut | Vous gardez le routage modèle ; clés LLM cloud = autre surface de risque |
2. OpenHuman vs OpenClaw : se souvenir vs exécuter
Beaucoup de lecteurs Nuvcloud utilisent déjà OpenClaw (docs.openclaw.ai, openclaw.ai). La distinction :
- OpenHuman agrège la vie numérique en mémoire consultable — brouillon de réponse depuis les mails récents, conflits réunion/commits, synthèse Notion + GitHub.
- OpenClaw transforme macOS en surface d’exécution orchestrée — webhooks, Gateway, runners, lien avec un Runner macOS auto-hébergé.
En équipe, le schéma sain : deux machines ou deux rôles — OpenHuman sur un cloud Mac toujours allumé pour « faire mûrir la mémoire », OpenClaw sur un autre nœud pour la CI. Avec une seule machine 16 Go, choisissez un métier et tenez-le ; n’activez pas tous les connecteurs + un runner parallèle sur le même volume.
OpenHuman ne remplace pas une pipeline de build ; OpenClaw ne remplace pas un graphe mail-docs unifié. Ils se complètent si vous séparez ressources et périmètres OAuth.
3. Quand un Mac cloud est le choix rationnel
OpenHuman tourne très bien sur MacBook local. Passez sur un Mac mini cloud dédié si au moins deux points vous concernent :
- Vous voyagez, fermez le capot ou avez une box instable — et vous voulez que l’auto-fetch continue.
- Le vault grossit de dizaines de Go par semaine et le SSD du portable sature.
- OAuth entreprise ou listes blanches SaaS exigent une IP de sortie stable que la box ne fournit pas.
- Vous refusez de mélanger tokens Gmail perso et logiciel Early Beta sur votre machine quotidienne.
Un nœud cloud achète disponibilité prévisible et disque extensible. SSH pour les logs, VNC ou partage d’écran pour les fenêtres OAuth — le même flux que dans le centre d’aide. Coût : OpEx plutôt que cycles « gratuits » du portable — d’où notre conseil : location journalière d’abord, trafic mail/calendrier réel une semaine, puis mensuel si la courbe se stabilise.
Le choix de région compte pour la latence vers les API SaaS et les récits conformité. Intégrations US → souvent US East / US West ; équipes APAC → Singapour, Japon, Hong Kong — la même logique que nos guides OpenClaw. L’objectif n’est pas la nouveauté : retirer sommeil, disque et churn IP du pipeline mémoire.
4. Dimensionner RAM M4 et disque avant de s’engager
OpenHuman n’est pas une appli statique. Connecteurs, indexation et export Markdown évoluent avec ce que vous branchez. Sous-dimensionner = swap, auto-fetch lent, nettoyage d’urgence — pas un message d’erreur poli.
| Profil | SKU de départ | Notes |
|---|---|---|
| Essai perso | M4 16 Go · 512 Go–1 To | Peu de connecteurs ; valider la pente disque en journalier |
| Intégrations lourdes (mail + Notion + GitHub + calendrier) | M4 24 Go · 1 To+ | fetch concurrent et index local gourmands en RAM |
| Même hôte qu’un runner CI | 24 Go · 1 To+ | vault mémoire et DerivedData sur chemins séparés |
Forfaits et SKU : tarifs Mac mini. En opération : louer 48–72 h, mesurer le vault une fois par jour, passer au mois seulement si croissance et pression mémoire restent acceptables. Pour une autre lecture « IA au niveau OS », voir notre comparatif Aluminium OS.
5. Première semaine sur Mac cloud : checklist
Traitez la première semaine comme un déploiement progressif, pas un « tout activer » : tokens OAuth et disque s’accumulent vite ; connecteurs par vagues facilitent le diagnostic.
- Vérifier macOS face à la release GitHub épinglée ; pare-feu entreprise : HTTPS et redirections OAuth.
- Paquets officiels uniquement ; autorisations par lots — mail/calendrier d’abord, puis Notion/GitHub.
- Vault sur chemin ou volume dédié ; sauvegardes SQLite + exports Markdown planifiées.
- SSH pour la santé quotidienne ; VNC quand l’UI demande un consentement OAuth.
- Documenter quels connecteurs sont prod vs expérimentaux pour en révoquer un sans tout casser.
sw_vers df -h / du -sh ~/Documents/* 2>/dev/null | sort -hr | head -5 # Comparer les plus gros dossiers semaine après semaine
Ces commandes ne sont pas magiques — c’est une habitude. Planifiez-les jusqu’à faire confiance à votre jeu de connecteurs. Si un répertoire bondit sans que le volume mail l’explique, coupez le dernier connecteur et remesurez avant d’agrandir le disque.
6. Sécurité : tokens et vault = réplique de personnalité
Gmail et Notion connectés, la base SQLite et l’arbre Markdown sur ce Mac valent une copie pro et perso de vous. Minimum : FileVault, SSH par clé seule, scopes OAuth minimaux. Mail d’entreprise sous DLP : pas d’instance perso sur boîtes managées sans accord écrit conformité.
Si les modèles passent par des API cloud, stockez les clés à part des sauvegardes vault et faites tourner comme les autres secrets. En Beta, suivez les releases GitHub ; évitez latest auto sur un hôte mémoire prod. Snapshot avant upgrade ; vérifiez que les connecteurs fetch encore.
L’isolation aide : OpenHuman sur un cloud Mac sans navigation quotidienne réduit le rayon d’explosion si un connecteur dérape — à condition de ne pas copier le vault sur une clé USB non chiffrée « pour tester ».
7. FAQ
Q1 : En quoi est-ce différent d’envoyer des PDF à ChatGPT ?
OpenHuman auto-fetch en continu depuis les intégrations live ; la mémoire évolue avec mails et calendriers, ce n’est pas un upload ponctuel.
Q2 : OpenHuman remplace-t-il OpenClaw ?
Non. OpenHuman agrège le contexte ; OpenClaw exécute l’automatisation et la CI. Hébergez sur des machines distinctes si les deux comptent.
Q3 : 16 Go suffisent ?
Pour 3–5 connecteurs sans runner sur la même machine, oui en essai. Intégrations lourdes ou CI partagée : visez 24 Go.
Q4 : Le vault peut-il saturer le disque ?
Oui — souvent plus vite qu’on ne croit. Chaque cycle auto-fetch peut ajouter corps de mails, entrées calendrier, pages Notion et métadonnées GitHub en SQLite et Markdown. Supprimer un mail dans le cloud ne réduit pas le local tant que l’intégration n’est pas élaguée. Chaque semaine sur le Mac cloud, ouvrez le Terminal et lancez du -sh sur le répertoire vault (ex. : 42G = 42 Go). Si Gmail fait exploser la courbe, vous avez peut‑être synchronisé des années d’historique — réautorisez avec une fenêtre plus courte ou archivez avant d’agrandir le disque. Désactivez les connecteurs inutiles.
Q5 : Faut-il absolument un cloud mac ?
Non. Mais pour un auto-fetch 7×24, un nœud toujours allumé bat un portable qui dort dans le train.
Q6 : Conflit avec Copilot ou Apple Intelligence ?
Couches différentes : assistants OS pour le bureau ; OpenHuman relie les SaaS en un graphe mémoire. Comparatif système : article Aluminium OS.
Garder le jumeau en ligne 24/7 : OpenHuman sur Mac mini cloud dédié
Memory Tree et auto-fetch exigent un hôte toujours allumé et un disque extensible. Nuvcloud : Mac mini M4 dédiés, SSH/VNC, multi-régions, facturation jour/semaine/mois—sans saturer votre MacBook principal.
Commencez par une location journalière pour mesurer disque et OAuth—forfaits Nuvcloud, puis OpenClaw/Runner sur un second nœud si besoin.