openclaw onboard / openclaw doctor pour valider l'environnement et la passerelle liée en 127.0.0.1. Ce tutoriel vise les équipes qui veulent des alertes et des retours CI dans Telegram ou Slack : droits minimaux, webhooks, validation des requêtes entrantes et FAQ quand rien n'arrive. Pour le durcissement passerelle et les jetons, lisez sécurité passerelle OpenClaw ; pour la santé du démon, LaunchAgent et healthcheck. L'accueil, le blog et le centre d'aide restent accessibles sans connexion.
Vérifications préalables : version, ports, liaison locale ou reverse proxy
Installez OpenClaw via le chemin documenté par le projet (script d'install ou paquet), puis imposez Node.js 22+ : node -v, which node. Lancez openclaw doctor (ou équivalent) et corrigez les avertissements avant de brancher des canaux IM.
node -v openclaw --version openclaw doctor
Contrôlez le port d'écoute configuré dans openclaw.json (ex. gateway.listen.port) : lsof -nP -iTCP:18765 -sTCP:LISTEN (adaptez le port). En production sur Mac distant, privilégiez 127.0.0.1 pour la passerelle et terminez TLS sur un reverse proxy (Caddy, nginx) si Telegram ou un fournisseur SaaS doit appeler un webhook HTTPS public.
| Modèle | Avantages | À vérifier |
|---|---|---|
Passerelle sur 127.0.0.1 uniquement | Surface d'attaque minimale ; SSH tunnel ou VPN pour l'admin. | Les webhooks entrants externes nécessitent un proxy avec certificat valide. |
| Reverse proxy vers la boucle locale | TLS, en-têtes, filtrage IP au bord. | Timeouts alignés sur les longues réponses modèle ; proxy_read_timeout. |
| Passerelle auto-hébergée vs panneau SaaS | Auto-hébergé : données et clés sur votre Mac ; SaaS : moins d'ops, dépendance fournisseur. | Matrice conformité (résidence des messages, SSO, journaux d'audit). |
Bot Telegram : création du jeton, écriture sécurisée et droits minimaux
Créez un bot via l'interface BotFather (commande /newbot), récupérez le token API et ne le commitez jamais. Isolez-le dans un fichier dédié, par ex. ~/.config/openclaw/.env.telegram en chmod 600, référencé depuis launchd ou votre gestionnaire de processus.
touch ~/.config/openclaw/.env.telegram chmod 600 ~/.config/openclaw/.env.telegram # contenu typique (noms à aligner sur votre version OpenClaw) : # TELEGRAM_BOT_TOKEN=... # TELEGRAM_ALLOWED_CHAT_IDS=123456789
Liste de droits minimaux : désactivez le « groupe privacy mode » du bot si vous devez lire les messages de groupe (selon politique interne) ; limitez les commandes exposées ; fixez une allowlist de chat_id dans la config passerelle pour ignorer tout expéditeur inconnu. Pour les mises à jour par webhook, configurez l'URL HTTPS publique qui pointe vers votre proxy, puis vérifiez le secret_token ou la signature attendue par OpenClaw (paramètre souvent nommé secret_token côté Telegram et répliqué dans openclaw.json sous la section canaux).
Test sortant depuis le Mac : curl -sS "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getMe" doit retourner ok:true. En cas d'échec, contrôlez HTTPS_PROXY et NO_PROXY comme dans notre guide sécurité passerelle.
Slack : Incoming Webhook vs application — tableau comparatif
| Approche | Sécurité | Audit / traçabilité | Limites / quotas |
|---|---|---|---|
| Incoming Webhook (URL unique) | URL = secret ; fuite = post arbitraire dans le canal. | Logs côté Slack limités ; corrélation fine délicate. | Débit modéré ; pas idéal pour rafales CI sans file. |
| Slack App + Bot Token (chat.postMessage) | OAuth, scopes explicites, révocation centralisée. | Meilleure traçabilité app/workspace. | Rate limits API ; gérer 429 avec backoff. |
| Slack App + Events (webhook entrant) | Signature X-Slack-Signature + timestamp anti-rejeu. | Événements horodatés dans l'app. | Endpoint public stable requis derrière TLS. |
Pour les alertes build, l'Incoming Webhook reste le plus rapide à prototyper ; pour une équipe et des audits, migrez vers une App avec scopes minimaux (chat:write, canal cible uniquement). Stockez SLACK_BOT_TOKEN ou l'URL webhook dans le même fichier chmod 600 que Telegram, séparé de openclaw.json versionné.
Pas à pas reproductible : d'OpenClaw au premier message test
Base. openclaw onboard si proposé, puis openclaw doctor. Vérifiez que la passerelle répond en local : curl -sf http://127.0.0.1:PORT/health (ajoutez -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" si activé).
Canaux. Dans openclaw.json, activez les blocs channels / notifications (noms exacts selon votre release) pour Telegram et Slack, en pointant vers les variables d'environnement plutôt que des valeurs en clair.
Webhook entrant (Slack → Mac). Exposez uniquement le chemin nécessaire via le reverse proxy ; vérifiez la signature et rejetez les requêtes sans en-tête attendu. Pour Telegram, enregistrez l'URL du webhook avec le même secret.
Test. Déclenchez la commande CLI ou l'action documentée pour « envoyer un message test » (souvent openclaw notify ou hook équivalent). Sinon, appelez l'endpoint interne documenté avec curl et un corps JSON minimal.
CI. Depuis le pipeline, POST vers la passerelle ou directement vers Slack/Telegram selon votre modèle ; gardez les secrets dans le coffre CI et une corrélation build_id dans le texte du message. Pour accélérer les pulls sur le nœud, voir Git et Docker sur Mac distant.
# Exemple de contrôle local (adapter PORT et chemin)
curl -sS -o /dev/null -w "%{http_code}\n" http://127.0.0.1:18765/health
FAQ : pas de messages, rejeu, rotation des jetons, callbacks CI
Rien n'arrive sur Telegram ou Slack. Vérifiez lsof sur le port passerelle, les journaux proxy (502/504), que le bot est bien dans le canal (Slack) ou que vous avez démarré une conversation privée (Telegram), et que les variables d'environnement sont bien injectées dans le plist launchd (launchctl print gui/UID / domaine système selon votre setup).
Protection contre la relecture. Slack : valider X-Slack-Request-Timestamp dans une fenêtre de quelques minutes et recalculer la signature HMAC. Telegram : utiliser secret_token sur le webhook et refuser les POST sans correspondance. Côté passerelle, gardez un cache d'IDs d'événements récents.
Rotation des jetons. Ajoutez le nouveau secret dans le fichier env, redémarrez le service (launchctl kickstart -k gui/UID/label.openclaw ou équivalent), envoyez un message test, puis révoquez l'ancien jeton côté BotFather ou Slack App.
Callbacks CI. Utilisez HTTPS, timeouts courts avec retry borné, corps sans secrets, et filtrez par IP ou VPN si la passerelle est exposée. Pour la résilience du nœud, croisez avec retry et récupération OpenClaw.
Synthèse et choix de nœud
Brancher Telegram et Slack sur une passerelle OpenClaw auto-hébergée, c'est surtout aligner trois choses : runtime Node 22+ et openclaw doctor propres, secrets IM en fichiers 600 hors git, et validation des webhooks entrants avant d'ouvrir le moindre port public. Les équipes CI gagnent en tranquillité en préférant une Slack App aux URLs webhook larges dès que l'audit compte.
Pour un Mac distant stable (sortie réseau prévisible, accès SSH documenté dans le centre d'aide), comparez les régions sur tarifs et réservez via achat. Poursuivez la série OpenClaw sur le blog et l'accueil MacPull.
Passez des alertes et des builds dans Telegram ou Slack sans sacrifier la sécurité
Articles OpenClaw, accueil, aide publique et achat — sans page de connexion obligatoire.