OpenClaw sur Google Chat
Le compte de service, l’application Chat, le point d’accès webhook seul, et n’exposer qu’un chemin
Google Chat est l’un des canaux qu’OpenClaw sert par des webhooks : l’extension officielle gère les messages privés et les espaces par l’API Chat, sur un point d’accès HTTP seulement, sans abonnement Pub/Sub. Cela façonne toute la configuration : un projet Google Cloud, un compte de service, une application Chat pointée vers une URL publique, et une décision sur la façon d’exposer ce seul chemin sans exposer la passerelle. Voici les étapes dans l’ordre de la documentation, comment l’application se trouve une fois en ligne, et la recette d’exposition.
La configuration
- Créez un projet Cloud et activez l’API Chat ; créez un compte de service sans permissions ; créez et téléchargez sa clé JSON et rangez le fichier sur l’hôte de la passerelle.
- Créez une application Chat dans la console : informations de l’application, fonctions interactives activées, adhésion aux espaces et aux conversations de groupe autorisée, une URL de point d’accès HTTP comme connexion, un point d’accès commun pour tous les déclencheurs réglé sur l’URL publique de la passerelle suivie du chemin du canal, et une visibilité limitée à des personnes précises de votre domaine.
- Passez l’état de l’application en ligne, puis configurez OpenClaw avec le fichier du compte de service, par une variable d’environnement pour le compte par défaut ou par la configuration, et l’audience du webhook qui doit correspondre à l’application ; l’assistant des canaux accepte les options d’audience et de webhook.
- Démarrez la passerelle ; Google Chat poste sur le chemin du webhook, et l’application s’ajoute depuis le bouton plus à côté des messages privés en cherchant son nom, parce qu’une application privée n’apparaît jamais dans la liste de la place de marché.
Les webhooks de Google Chat exigent un point d’accès HTTPS public.
N’exposer qu’un chemin
La documentation est précise : n’exposez que le chemin du canal à Internet et gardez le tableau de bord et tout autre point d’accès privés. La façon recommandée est Tailscale dans deux rôles, Serve pour le tableau de bord sur un port réservé au tailnet et Funnel pour le seul chemin du webhook, après avoir vérifié à quelle adresse la passerelle est liée, boucle locale, toutes les interfaces ou une adresse du tailnet, parce que la cible de Serve en dépend.
À garder en tête
- La visibilité est le contrôle d’accès côté Google : l’application n’est disponible que pour les personnes et groupes que vous listez, et l’appairage est le contrôle d’accès côté OpenClaw.
- L’audience dans la configuration doit correspondre à la configuration de l’application Chat, sinon la validation du webhook échoue en silence vu de l’extérieur.
- La clé du compte de service est un identifiant comme un autre : rangez-la hors de l’espace de travail et référencez-la, ne la collez jamais dans la discussion.
OpenClaw et Tailscale explique Serve et Funnel, et L’appairage dans OpenClaw l’étape d’approbation qui suit le premier message.
Sur Diali
Sur Diali, Google Chat est sur la feuille de route plutôt que dans la liste des canaux à connecter ; le projet Cloud et l’application Chat resteraient à vous, et le chemin public du webhook serait à nous à exposer. OpenClaw hébergé sur Diali est l’assistant, et Slack sur Diali le canal professionnel qui se connecte aujourd’hui.
- Un compte de service, une application Chat, un chemin de webhook, pas de Pub/Sub.
- Exposez un seul chemin avec Funnel ; gardez le tableau de bord sur Serve.
- La visibilité garde le côté Google ; l’appairage garde le côté OpenClaw.
Arrêtez de lire, construisez le vôtre
Configurez un agent, choisissez un canal, et faites-le travailler dans l’application que vous gardez déjà ouverte.
