01_La messagerie comme poste de pilotage
OpenClaw prend en charge WhatsApp, Telegram, Slack, Discord, Microsoft Teams, Signal et iMessage comme canaux de première classe. Un même déploiement peut servir plusieurs plateformes à la fois, avec un contexte et une mémoire partagés sur tous les canaux. La messagerie devient ainsi le poste de pilotage naturel pour le réveil à distance et l'envoi de tâches : vous envoyez une requête depuis votre téléphone ou Slack, et l'agent s'exécute sur la machine où OpenClaw est installé—qu'il s'agisse d'un Mac local ou d'un nœud M4 dédié dans le cloud.
Les cas d'usage sont immédiats : déclencher des commandes terminal depuis le téléphone, confier des tâches d'extraction de fichiers ou de données, demander une recherche web avec des résultats structurés, ou planifier des workflows récurrents. L'agent peut répondre sur le même canal (WhatsApp, Slack, etc.) ou dans un canal choisi lorsque l'appel passe par l'API webhook. L'effort d'intégration varie selon la plateforme : Telegram est souvent la plus rapide à mettre en route (de l'ordre de trente à soixante minutes avec un token bot), tandis que WhatsApp et Teams exigent en général une configuration entreprise ou locataire et peuvent prendre quelques heures.
Pour les équipes créatives et techniques, ce modèle change la donne : au lieu de multiplier les outils et les tableaux de bord, une seule interface conversationnelle—celle que vous utilisez déjà—devient le levier pour lancer des builds, consulter l'état des nœuds ou déclencher des pipelines. Le matériel Apple Silicon, qu'il soit en local ou sur un nœud MACGPU, assure une exécution stable et prévisible ; la messagerie assure la continuité du contrôle, où que vous soyez.
02_API Webhook : réveil à distance et envoi de tâches
La Gateway expose une surface HTTP webhook réduite lorsque hooks.enabled est à true. Deux endpoints comptent pour la télécommande : POST /hooks/wake et POST /hooks/agent. Chaque requête doit être authentifiée. Les jetons en query string sont rejetés ; vous devez envoyer le secret partagé via Authorization: Bearer <token> ou x-openclaw-token: <token>. Le token de hook doit être distinct des jetons d'authentification de la gateway et rester derrière loopback, un tailnet ou un reverse proxy de confiance.
POST /hooks/wake déclenche un heartbeat. Le payload est {"text": "description de l'événement", "mode": "now"}. Avec mode: "now" le heartbeat s'exécute immédiatement ; avec mode: "next-heartbeat" l'événement est mis en file pour le prochain cycle périodique. C'est la brique primitive du réveil à distance : un système externe (CI, calendrier, pont email) peut indiquer à OpenClaw de se réveiller et de traiter le travail en attente.
POST /hooks/agent envoie une tâche à un agent. Le champ requis est message (le prompt). Les champs optionnels incluent name (nom lisible du hook, ex. "Email"), agentId (router vers un agent précis ; restreint par hooks.allowedAgentIds), wakeMode ("now" ou "next-heartbeat"), deliver (envoyer ou non la réponse de l'agent vers un canal de messagerie), channel (ex. whatsapp, telegram, slack, discord, last), et to (identifiant du destinataire : numéro, chat ID ou channel ID). Vous pouvez aussi surcharger model et thinking et définir timeoutSeconds. L'API renvoie 202 lorsque l'exécution asynchrone a été acceptée.
L'identité de session est importante. Par défaut, les payloads des requêtes ne peuvent pas définir sessionKey ; le schéma recommandé est de définir hooks.defaultSessionKey (ex. "hook:ingress") et de garder allowRequestSessionKey: false. Si vous avez besoin de sessions définies par l'appelant, activez l'option et restreignez allowedSessionKeyPrefixes (ex. ["hook:"]) pour limiter les abus. Restreignez allowedAgentIds afin que seuls les agents voulus soient ciblables par les appelants webhook.
03_Configuration des canaux et destinataires
Chaque plateforme de messagerie nécessite des identifiants et une configuration dans ~/.openclaw/openclaw.json (ou le chemin de configuration effectif). WhatsApp exige en général une vérification Business API et l'enregistrement d'un webhook. Telegram nécessite un token bot obtenu auprès de BotFather. Slack utilise OAuth ; Discord et les autres ont leur propre configuration d'application. La documentation OpenClaw et les guides communautaires décrivent les étapes exactes par canal.
Lorsque vous appelez /hooks/agent avec deliver: true, vous pouvez définir channel sur last (utiliser le dernier destinataire de la session principale), ou explicitement sur whatsapp, telegram, slack, discord, signal, imessage ou msteams. Le champ to identifie le destinataire : numéro de téléphone pour WhatsApp/Signal, chat ID pour Telegram, channel ou user ID pour Slack/Discord, conversation ID pour Teams. Un même webhook peut ainsi piloter des tâches et envoyer les réponses au bon endroit sans passer par l'interface de chat principale.
WhatsApp, Telegram, Slack, Discord, Teams, etc.
Réveil à distance et envoi de tâches
Mémoire et état partagés sur tous les canaux
04_Mappings et 50+ intégrations de services
Au-delà de /hooks/wake et /hooks/agent, la Gateway supporte des noms de hook personnalisés via hooks.mappings. Un mapping peut faire correspondre un payload entrant (par ex. par source ou chemin), puis exécuter une action wake ou agent avec des templates ou des transforms optionnels. Les présets intégrés comme Gmail (hooks.presets: ["gmail"]) et le flux openclaw webhooks gmail setup se branchent sur Gmail Pub/Sub pour que les nouveaux emails réveillent l'agent ou postent une tâche. Des schémas similaires s'appliquent aux webhooks GitHub, aux systèmes CI et aux outils internes.
Les transforms peuvent être des modules JavaScript ou TypeScript sous hooks.transformsDir, ce qui permet de normaliser les payloads tiers en message et métadonnées OpenClaw. La documentation exige que le répertoire des transforms reste sous la racine de configuration (ex. ~/.openclaw/hooks/transforms) et que les chemins de traversée soient rejetés. Pour les sources non de confiance, conservez le wrapper de sécurité par défaut ; n'activez allowUnsafeExternalContent: true que pour des endpoints internes pleinement de confiance.
Le chiffre « 50+ services » reflète la combinaison des canaux natifs (WhatsApp, Telegram, Slack, Discord, Teams, Signal, iMessage), des mappings pilotés par webhook (Gmail, GitHub, HTTP personnalisé), et la possibilité d'en brancher d'autres via des transforms et de l'automatisation externe. Depuis une seule instance OpenClaw vous centralisez ainsi les déclencheurs issus de l'email, du chat, des trackers de tickets et des planificateurs de type cron, puis vous routez les réponses vers le canal approprié.
05_Types de tâches et périmètre de sécurité
L'envoi de tâches ne se limite pas à « lancer un script » : il peut s'agir de consulter l'état des nœuds, de déclencher une compilation Xcode, de récupérer un dépôt et d'exécuter les tests, ou de demander à l'agent une revue de code ou une note de release. L'essentiel est de définir côté agent un « ensemble d'instructions exécutables » clair et des frontières de permission, afin d'éviter les risques liés à l'exécution de commandes arbitraires.
Recommandation : mapper le langage naturel ou des formulations fixes (ex. « déploie staging », « état nœuds cpu ») vers des actions en liste blanche ; les opérations sensibles peuvent exiger une double confirmation ou être limitées à certains canaux ou utilisateurs. Vous gardez ainsi l'expérience « une phrase suffit » tout en limitant les erreurs et les dépassements de droits. Le tableau suivant résume trois types de tâches typiques et les stratégies conseillées.
| Type de tâche | Exemple d'instruction | Stratégie recommandée |
|---|---|---|
| Consultation | « État des nœuds », « Dernier résultat de build » | Lecture seule, sans effet de bord ; peut être ouvert |
| Déclenchement | « Déploiement staging », « Lancer les tests nightly » | Mapper vers des pipelines prédéfinis ; liste blanche |
| Sensible | « Exécuter une commande arbitraire », « Modifier la config prod » | Interdit ou double confirmation + contrôle des droits |
06_Exemple : réveil et réponse vers Slack
Un flux typique : un événement externe (ex. un push GitHub ou un cron) appelle /hooks/wake avec mode: "now" pour que l'agent exécute un heartbeat et traite le travail en attente. Alternativement, le même système peut appeler /hooks/agent avec un message précis, channel: "slack" et to réglé sur l'ID du canal ou de l'utilisateur Slack. L'agent s'exécute une fois et sa réponse est livrée à cette destination Slack. Inutile d'ouvrir l'interface OpenClaw : toute la boucle passe par la messagerie et les webhooks.
Les codes de réponse de la Gateway sont cohérents : 200 pour /hooks/wake, 202 pour /hooks/agent (exécution asynchrone acceptée). En cas d'échec vous obtenez 401 (token absent ou invalide), 400 (JSON invalide ou champs requis manquants), 413 (payload trop volumineux) ou 429 (limite de débit après échecs d'auth répétés ; consulter Retry-After). Loggez ces réponses dans votre CI ou orchestrateur pour détecter une mauvaise configuration ou un abus.
07_Sécurité et durcissement en production
Utilisez un token de hook dédié et ne réutilisez pas l'authentification de la gateway. Restreignez hooks.allowedAgentIds pour que les appelants webhook ne puissent pas cibler n'importe quel agent ; n'omettez pas cette option ou n'utilisez "*" que dans des environnements maîtrisés. Gardez allowRequestSessionKey à false et définissez defaultSessionKey sauf besoin explicite de sessions choisies par l'appelant. Lorsque vous autorisez des surcharges, restreignez allowedSessionKeyPrefixes. La Gateway limite le débit après échecs d'authentification répétés par client ; les réponses incluent 401 en cas d'échec d'auth, 400 pour un payload invalide, 413 pour des payloads trop volumineux, et 429 avec Retry-After après trop d'échecs.
Exposez l'endpoint de hook en loopback ou derrière un reverse proxy qui termine le TLS et restreint l'accès par IP ou tailnet. Évitez de logger les payloads bruts qui peuvent contenir des secrets. Si vous exposez les hooks sur l'internet public (ex. pour des webhooks SaaS), utilisez un proxy qui valide les signatures ou les jetons avant de transférer.
08_Exécuter OpenClaw sur un nœud M4 dédié
La télécommande prend tout son sens lorsque l'agent tourne 24/7 sur une machine toujours allumée et joignable. Un Mac M4 dédié dans le cloud—par exemple un nœud bare-metal MACGPU—offre un hôte stable pour la Gateway OpenClaw et les agents, avec une IP fixe et sans cycles de veille. Vous pointez alors les webhooks WhatsApp Business API, Telegram ou Slack vers cet hôte (via un reverse proxy et des règles pare-feu), et vous utilisez la même API webhook depuis votre CI ou vos services internes.
Étapes de déploiement : provisionner le nœud, installer OpenClaw et ses dépendances, configurer openclaw.json avec hooks.enabled: true, le token et la politique d'agents et de session autorisés. Ajoutez les identifiants des canaux pour WhatsApp, Telegram et/ou Slack. Exposez uniquement les ports nécessaires via un reverse proxy avec TLS et restreignez les IP sources ou utilisez un tailnet. Vous pouvez faire tourner la Gateway sous un process manager pour qu'elle redémarre en cas de panne. Une fois en place, les messages de n'importe quel canal connecté et les webhooks des 50+ services peuvent réveiller et piloter le même agent, avec les réponses livrées vers le canal choisi.
Pour les studios et équipes créatives qui s'appuient sur Apple Silicon pour la compilation, le rendu ou l'inférence, ce schéma permet de garder un accès continu à la puissance de calcul sans gérer soi-même le matériel : le nœud M4 reste disponible, et vous gardez le contrôle depuis votre messagerie, que vous soyez en déplacement ou au bureau.
09_Résumé
OpenClaw transforme WhatsApp, Telegram, Slack et les autres plateformes de messagerie en postes de télécommande pour votre agent. POST /hooks/wake déclenche un heartbeat ; POST /hooks/agent envoie une tâche avec canal et destinataire optionnels. Utilisez les mappings et transforms pour intégrer Gmail, GitHub et vos systèmes personnalisés, et durcissez avec l'authentification par token, allowedAgentIds et la politique de session. Pour une disponibilité 24/7, exécutez la Gateway sur un nœud M4 dédié et routez le trafic messagerie et webhook via un proxy sécurisé. C'est le cœur d'un workflow OpenClaw à distance avec plus de cinquante intégrations de services—et la messagerie comme interface de contrôle, où que vous soyez.