OpenClaw 2026 : comment choisir son chemin d'installation ? install.sh officiel, npm et Docker Compose — matrice de décision + checklist SSH sans écran

TL;DR — tranchez tôt

Recommandation par défaut pour un Mac « serveur » dédié : commencez par le install.sh officiel si vous voulez rester le plus proche de ce que les mainteneurs testent au quotidien, avec le moins de surprises de type « chez moi ça marche ».

Choisissez npm lorsque vous itérez vite sur les versions de Node, que vous avez besoin d'isolation par utilisateur, ou que vous standardisez déjà nvm / fnm sur cette machine.

Choisissez Docker Compose pour des piles reproductibles, un meilleur contrôle de la zone d'impact, ou lorsqu'OpenClaw cohabite avec d'autres services conteneurisés — au prix de plus de pièces mobiles sur macOS (bind mounts, réseau, permissions fichiers).

Pour cadrer le débat hébergement vs cloud au sens large, voir aussi Comparaison du déploiement sécurisé d'OpenClaw 2026 : auto-hébergé vs environnements cloud SSH/CLI.

Ce que recouvre réellement le « chemin d'installation »

En 2026, les équipes regroupent en général quatre décisions liées :

• Canal de livraison : bootstrap shell (install.sh), gestionnaire de paquets (npm) ou images (docker compose).
• Propriété : installation système vs utilisateur macOS unique — critique pour SSH et les jobs launchd.
• Emplacement de l'état : où vivent configs, identifiants, caches et journaux (répertoire personnel, /usr/local, volumes nommés…).
• Scénario de mise à jour : rafraîchissement en une commande, semver épinglée, ou digest d'image figé.

Un décalage ici est souvent la cause des « ça marche dans le Terminal mais pas en SSH » — surtout avec des shells non interactifs.

Option A — install.sh officiel

Forces

• Alignement avec les tests amont ; moins de cas limites non documentés.
• Souvent des chemins et attentes posés en une passe — pratique sur un Mac mini neuf ou une image « build node ».
• Remise à l'ops simple : « lancer l'installateur officiel, puis appliquer notre couche de config ».

Limites

• Peut exiger des droits élevés ou des validations manuelles sur les postes verrouillés.
• Moins fin que d'épingler patch par patch Node/npm sans garde-fous maison.

Option B — npm (global ou par projet)

Forces

• Avance et retour arrière rapides si Node est piloté par nvm ou équivalent.
• Multi-utilisateurs propres : plusieurs comptes sur le même Mac peuvent porter des versions différentes.
• Cohérent si vous déployez déjà d'autres CLI JavaScript de la même manière.

Limites

• Les sessions SSH chargent souvent un profil différent de l'interface graphique — risque de mauvais Node sur le PATH.
• Les installs globales dérivent ; documentez la LTS Node et les lockfiles supportés.

Option C — Docker Compose

Forces

• Runtime reproductible : même fichier compose entre préprod et mini « prod ».
• Limites de ressources et politiques réseau natives — utile si OpenClaw partage la machine avec des builds ou d'autres agents.
• S'accorde bien avec l'infra-as-code et le pin par digest d'image.

Limites

• Permissions et volumes sur macOS surprennent encore — testez les restaurations, pas seulement le premier démarrage.
• Un démon de plus à patcher (Docker Desktop, Colima, etc.).

Pour un labo CI entièrement piloté en SSH sans écran, les pratiques de Guide 2026 : labo CI automatisé sur Mac mini via SSH — pratiques headless complètent bien cette section.

Matrice de décision (synthèse)

Mac distant sans écran + SSH : checklist de dépannage

Parcourez cette liste avant de conclure qu'OpenClaw lui-même est en panne :

• Connexion à distance : SSH activé pour le bon utilisateur ; pas de mélange entre comptes « locaux uniquement » et comptes réseau.
• PATH non interactif : comparez which node / which docker dans le Terminal graphique et via ssh user@host 'which node' ; harmonisez ~/.zprofile, ~/.zshenv, ou des chemins explicites dans les EnvironmentVariables des plist launchd.
• Type de session : certains agents ont besoin d'une session console connectée ou d'un Launch Agent correct — le pur SSH ne reproduit pas toujours l'accès au trousseau graphique.
• Veille / Power Nap : désactivez la veille pour les hôtes sans présence ; vérifiez la politique pmset vs votre SLA.
• Accès disque complet / TCC : si des outils touchent Bureau/Documents ou certaines API, les approbations peuvent manquer pour le binaire invoqué par SSH — vérifiez Réglages système → Confidentialité.
• Contexte Docker : le CLI via SSH doit viser le même moteur que votre contexte local (docker context ls).
• Pare-feu et VPN / Tailscale : règles entrantes, sous-réseaux, DNS scindé ; routes obsolètes simulent souvent une « panne ».
• Pression disque et inodes : journaux compose et caches modèles peuvent remplir un petit SSD sans bruit.
• Dérive d'horloge : le TLS vers les fournisseurs échoue de façon opaque si l'heure dérive — activez NTP.

Pourquoi Mac mini et macOS restent un socle solide pour cette pile

L'automatisation de type OpenClaw fonctionne mieux sur un hôte Unix réel avec des permissions prévisibles, une consommation électrique stable et un support de premier ordre pour SSH, les conteneurs et la toolchain développeur. Un Mac mini M4 offre des performances Apple Silicon avec une veille de l'ordre de ~4 W — idéal pour des agents qui doivent tourner la nuit sans ventilateur ni thermal throttle surprise. macOS combine Gatekeeper, SIP et FileVault avec une chaîne d'outils qui évite les environnements « bicephales » typiques des postes multi-OS, ce qui raccourcit le debug à distance lorsqu'un service headless échoue.

Sur le long terme, du métal dédié bat des VM recréées sans cesse : moins de surprises pilotes, propriété claire des disques et des secrets, et moins de charge opérationnelle pour les petites équipes qui veulent que le chemin d'installation reste ennuyeux pendant des mois.

Si vous voulez déployer ce guide sur du matériel fait pour rester allumé en continu, le Mac mini M4 reste l'un des points d'entrée les plus rationnels en 2026. Découvrez les offres de location Mac mini sur SSHMac et lancez votre hôte OpenClaw sereinement.