2026 — Guide complet d'installation et de configuration OpenHuman : tutoriel pas à pas de zéro à la mise en service

2. Ne pas installer le mauvais projet : assistant de bureau vs SDK WebGL

OpenHuman (ce guide) désigne l'assistant IA personnel de bureau open source tinyhumansai/openhuman : interface graphique, Memory Tree, coffre Markdown style Obsidian, 118+ intégrations OAuth, Ollama local en option. Par défaut, les services hébergés OpenHuman gèrent connexion, routage de modèles, proxy de recherche et OAuth via Composio (BYOK / Composio direct possibles dans les réglages).

Il existe aussi un SDK OpenHuman WebGL pour avatars 3D — orienté personnages web, hors ce guide. Si votre objectif est « base de connaissances personnelle + contexte mail/calendrier/dépôts », utilisez le dépôt de bureau et la page tinyhumans.ai/openhuman.

Ce n'est pas non plus un simple onglet de chat web : OpenHuman met l'accent sur données de workflow locales + tirages planifiés d'intégrations. Face aux agents CLI, il propose interface graphique + onboarding court — pas de fichier de config obligatoire avant le premier message.

3. Trois points de friction typiques

1. Contrainte : confondre « installé » et « il me comprend déjà ». La doc officielle place Memory Tree, coffre Markdown, config workspace et état d'exécution local sur votre machine ; connexion, routage modèles, proxy recherche et OAuth par défaut peuvent rester hébergés. Sans intégration connectée et sync terminée, l'agent ne peut que généraliser.
2. Coût caché : permissions trop larges et comptes de production dès le jour 1. Une autorisation OAuth peut couvrir mail, calendrier, dépôts, etc. Tant que le produit est en Beta, commencez par une boîte test ou un dépôt GitHub de test, vérifiez périmètres et chemins de révocation, puis branchez les vraies données.
3. Stabilité et audit : ne pas savoir où sont mémoire et journaux. Désinstaller-réinstaller sans notes peut effacer la seule trace SQLite et coffre. Notez le chemin workspace, les ID d'intégration et le mode modèle (hébergé / BYOK / Ollama) pour revenir en arrière.

4. Checklist avant installation

Objectif : découvrir réseau ou disque à mi-parcours fait perdre des heures. Critère : chaque point coché avant téléchargement.

• OS : macOS (Apple Silicon ou Intel), Windows 10/11 (64 bits), bureau Debian/Ubuntu ou Arch. Versions minimales selon la Release courante ; produit en Early Beta — chemins UI susceptibles de changer.
• Matériel : 16 Go+ RAM recommandés (Ollama local exige plus) ; réserver ≥5 Go disque (app + coffre + SQLite + cache modèles).
• Réseau : Accès GitHub, tinyhumans.ai et domaines de redirection OAuth ; proxy d'entreprise et pop-ups navigateur si besoin.
• Comptes : Compte produit OpenHuman ; clés API fournisseurs si BYOK ; Ollama installé et modèle tiré si inférence locale.
• Données test : Gmail test / dépôt GitHub test — ne pas connecter Slack entreprise ou boîte de production au premier lancement.
• Permissions : macOS peut demander notifications, micro (voix), accès fichiers ; sous Linux, noter AppImage + Wayland (issue officielle #2463).

5. Sources de téléchargement et vérification de sécurité

Priorité officielle (README) : ① Site / GitHub Release → ② Gestionnaires natifs (Homebrew, apt signé, MSI) → ③ Script (pas de signature autonome du script — à n'utiliser qu'en connaissance de cause).

En cas d'échec : fichier corrompu → retélécharger depuis Release ; blocage SmartScreen / Gatekeeper → confirmer l'éditeur puis autoriser ; ne pas remplacer par des « miroirs » inconnus.

6. Installation sur trois plateformes

6.1 macOS (Homebrew recommandé)

brew tap tinyhumansai/core
brew install openhuman

Sinon télécharger le .dmg depuis Release et glisser dans Applications. Réussite : OpenHuman s'ouvre depuis le Launchpad. Échec : « développeur non vérifié » → Réglages système → Confidentialité → Ouvrir quand même ; autoriser notifications/micro/fichiers selon les fonctions utilisées.

6.2 Windows (MSI signé)

Télécharger le .msi depuis la dernière release et lancer l'installeur. Sur SmartScreen, confirmer l'éditeur. Réussite : raccourci menu Démarrer. Échec : politique entreprise, antivirus, pare-feu bloquant le callback OAuth navigateur.

6.3 Linux (apt recommandé ; prudence AppImage)

sudo apt-get install -y --no-install-recommends gnupg2 curl ca-certificates
curl -fsSL https://tinyhumansai.github.io/openhuman/apt/KEY.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/openhuman.gpg
echo "deb [signed-by=/etc/apt/keyrings/openhuman.gpg arch=amd64] \
  https://tinyhumansai.github.io/openhuman/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/openhuman.list
sudo apt-get update
sudo apt-get install -y openhuman

Sous Arch : recette AUR openhuman-bin (yay -S openhuman-bin — vérifier la fiche AUR). AppImage peut échouer sous Wayland ou certaines Arch (issue #2463) ; sur Debian/Ubuntu préférer .deb / apt. Réussite : entrée menu bureau. Échec : bibliothèques manquantes, variables Wayland, session X11.

6.4 Matrice de choix par plateforme

Désinstallation / réinstallation : déconnecter d'abord toutes les intégrations OAuth et sauvegarder les coffres importants ; après désinstallation, workspace et SQLite peuvent rester dans le profil utilisateur — confirmer les chemins officiels avant de supprimer la seule copie mémoire.

7. Premier lancement et connexion au compte

1. Lancer l'app et choisir un répertoire workspace dédié — éviter de pointer tout le dossier personnel.
2. Se connecter avec le compte produit OpenHuman (flux hébergé par défaut). Réussite : Réglages affichent l'état connecté.
3. Parcourir canal de mise à jour et options confidentialité (notifications, voix, proxy recherche) — garder les défauts jusqu'au premier passage réussi, puis affiner.

Échec : page de connexion vide → navigateur par défaut, désactiver bloqueurs pub ; échecs répétés → heure système, DNS, proxy ; disponibilité régionale et abonnement selon la doc courante — ce guide ne garantit pas les mêmes fonctions partout.

8. Configuration des modèles et BYOK

Modèles hébergés (défaut) : le backend OpenHuman assure le routage de modèles (raisonnement / rapide / vision). Tarifs et quotas sur la page compte — susceptibles d'évoluer.

BYOK (Bring Your Own Key — « apportez votre propre clé ») : saisir les clés API fournisseurs dans les réglages ; vous payez l'usage et gérez les quotas — utile pour contrats entreprise ou maîtrise des coûts.

Modèles locaux (Ollama) : la doc supporte l'IA locale ; la mémoire unifiée Apple Silicon aide les petits modèles, mais les gros modèles restent limités par la RAM — tester latence et qualité vous-même.

Réussite : envoyer « Présente-toi en une phrase » et obtenir une réponse cohérente. Échec : hébergé → abonnement/réseau ; BYOK → permissions clé ; Ollama → service à l'écoute et nom de modèle correct.

9. Intégrations et configuration des permissions

OpenHuman expose Gmail, Slack, Notion, GitHub, Calendar, Drive et 118+ connecteurs via la couche Composio. Par défaut, OAuth et appels d'outils passent par le backend hébergé ; en Composio direct, ajoutez votre clé API Composio et hébergez vous-même les webhooks temps réel.

OAuth : connexion via navigateur pour accorder à l'application un accès limité en votre nom. Lire les périmètres (scopes) sur l'écran de consentement — n'accorder que ce dont le cas pratique a besoin.

Réussite : statut Connected et callback OAuth sans erreur. Échec : pop-ups bloquées, SSO entreprise, état Composio, proxy réseau.

10. Comment accepter le système de mémoire

Pour les débutants, la mémoire OpenHuman fonctionne ainsi :

• Memory Tree : organise les données tirées des intégrations en résumés hiérarchiques stockés localement en SQLite.
• Coffre Markdown (compatible Obsidian) : les mêmes connaissances deviennent des fichiers .md consultables dans Obsidian.
• auto-fetch : chaque connexion active tire de nouvelles données environ toutes les 20 minutes — sans script de polling manuel.

Étapes d'acceptation : connecter une intégration test → attendre au moins un cycle de 20 minutes → vérifier nouveaux blocs dans Mémoire ou le coffre → poser une question que seules les données test peuvent résoudre (mot-clé unique d'un mail test).

Réussite : la réponse cite les bonnes sources. Échec : intégration inactive, sync incomplète, ou question sur la prod alors que seule la source test est connectée (hallucination « contexte vide »).

11. Premier cas pratique : boîte test « résumé hebdo + tâches »

Objectif : valider modèle, intégration, mémoire, sortie et boucle de révocation en une passe.

1. Créer un compte Gmail test ; s'envoyer 2–3 mails à sujets explicites (« Discussion budget Q2 », « Rapport hebdo vendredi »).
2. Dans OpenHuman, connecter uniquement cette boîte ; terminer OAuth.
3. Attendre le premier auto-fetch (≥20 minutes recommandé) ; confirmer du contenu nouveau dans le coffre / Mémoire.
4. Demander : « À partir des mails récents de ma boîte test, produis un résumé hebdomadaire et une liste de tâches, en citant l'email source de chaque point. »
5. Vérifier : le résumé correspond aux mails test ; pas de sujets inventés ; exporter la sortie si l'app le permet.
6. Révoquer l'autorisation côté OpenHuman et Google ; confirmer que l'agent ne cite plus cette boîte.

Réussite : sortie alignée sur les mails test, sources vérifiables, accès coupé après révocation. Échec : isoler couche modèle (④) et couche mémoire (⑥) — ne pas mélanger le dépannage.

12. Problèmes courants (dépannage par couches)

13. Checklist après mise en service : étendre une fois la boucle stable

• Révoquer les OAuth de test, puis ajouter boîte/dépôt réels une intégration à la fois.
• Sauvegarder workspace, coffre et captures des réglages clés ; noter mode modèle et coût mensuel approximatif.
• Lire la page officielle Confidentialité et sécurité ; revoir notifications et voix.
• Conserver une voie de désinstallation : savoir où sont les données avant de supprimer la seule bibliothèque mémoire.

Runbook en sept étapes : préparation → install officielle → connexion → test modèle → une intégration à faible risque → attendre la mémoire → cas pratique et révocation. Ensuite seulement : Slack, Notion et workflows long terme.