Slack et OpenClaw : configurer le canal officiel

Introduction

Le mot-clé slack skill OpenClaw désigne souvent, à tort, une classe Python. L'intégration utile est un canal officiel qui relie messages directs et canaux Slack au Gateway. Choisissez-la quand une équipe doit dialoguer avec l'assistant dans Slack ou recevoir ses livraisons. Pour une notification sortante unique, un webhook déterministe peut être plus simple : évitez un canal complet sans besoin conversationnel.

Le parcours actuel passe par le plugin @openclaw/slack, une Slack App et channels.slack dans ~/.openclaw/openclaw.json. Socket Mode évite une URL publique et convient aux Gateways derrière un pare-feu ; HTTP vise les déploiements avec terminaison HTTPS. Ce tutoriel couvre installation, politiques, routage, tests et exploitation sans BaseSkill ni slack-sdk.

Résumé rapide

1. Installez le plugin de canal officiel avec openclaw plugins install @openclaw/slack.
2. Créez une Slack App à partir du manifeste fourni par la documentation OpenClaw actuelle.
3. En Socket Mode, récupérez un App-Level Token avec connections:write et le Bot User OAuth Token.
4. Configurez les références vers SLACK_APP_TOKEN et SLACK_BOT_TOKEN.
5. Définissez qui peut parler au bot, quels canaux sont permis et si une mention est obligatoire.
6. Démarrez le Gateway, testez un message direct puis un canal autorisé.

Un skill SKILL.md peut ensuite décrire le ton ou la procédure de réponse. Il n'installe pas Slack et ne détient pas les tokens.

Canal, plugin, outil et skill : qui fait quoi ?

Élément	Rôle avec Slack
Canal	Transporte messages, threads, fichiers et interactions entre Slack et le Gateway.
Plugin Slack	Implémente cette connexion et ses capacités dans OpenClaw.
Outil message	Permet à l'agent d'envoyer une réponse ou un message autorisé sur une route connue.
Skill	Apprend à l'agent quand notifier, quel format employer et quand escalader.
Automatisation	Déclenche un rapport à une heure précise et peut le livrer vers Slack.
Script externe	Produit éventuellement des données, mais n'est ni le canal ni un skill.

Cette séparation change la conception. Pour une alerte quotidienne, vous n'avez pas besoin de réimplémenter l'API Slack : configurez le canal puis livrez le résultat d'une automatisation. Pour une procédure de support, un skill peut guider l'agent, tandis qu'un binding route le bon espace Slack vers l'agent support. Le guide des outils d'un agent IA détaille ces responsabilités.

Installer et configurer Slack

Installer le plugin

openclaw plugins install @openclaw/slack

L'installation enregistre et active le plugin, mais elle ne suffit pas : la Slack App et les credentials restent à configurer et à tester séparément.

Créer la Slack App

Dans l'interface Slack Apps, choisissez Create New App, puis From a manifest. Utilisez le manifeste à jour fourni par la documentation OpenClaw plutôt qu'une liste de scopes recopiée dans un ancien tutoriel. Le manifeste officiel couvre les événements, commandes et permissions attendus par le canal.

Après création :

1. générez un App-Level Token avec le scope connections:write ;
2. installez l'app dans le workspace ;
3. copiez le Bot User OAuth Token ;
4. conservez ces deux valeurs hors du dépôt.

Exposez-les au processus Gateway :

export SLACK_APP_TOKEN="votre-app-token"
export SLACK_BOT_TOKEN="votre-bot-token"

Configurer Socket Mode

La forme suivante utilise des références d'environnement plutôt que des secrets en clair :

{
  channels: {
    slack: {
      enabled: true,
      mode: "socket",
      appToken: {
        source: "env",
        provider: "default",
        id: "SLACK_APP_TOKEN",
      },
      botToken: {
        source: "env",
        provider: "default",
        id: "SLACK_BOT_TOKEN",
      },
    },
  },
}

Appliquez ce réglage avec les surfaces de configuration OpenClaw prévues pour votre installation, puis démarrez ou redémarrez le Gateway :

openclaw gateway restart
openclaw channels status --probe

Le mode HTTP nécessite une URL publique, le Bot Token et le Signing Secret. Ne le choisissez pas uniquement pour « faire plus production » : Socket Mode et HTTP couvrent les mêmes fonctions principales, mais répondent à des contraintes réseau différentes.

Testez séparément authentification, réception et émission. openclaw channels status --probe valide la connexion, mais un vrai message permet de vérifier les événements et le routage. Envoyez d'abord un DM autorisé, puis une mention dans un canal permis, puis un message sans mention. Ce dernier doit rester silencieux si requireMention est actif. Contrôlez enfin une pièce jointe ou un thread seulement si ces capacités font partie du besoin.

Pour la production, surveillez les reconnexions Socket Mode, les erreurs d'autorisation et les échecs de livraison. Une app Slack peut rester installée alors qu'un token a été révoqué. Conservez une procédure de rotation et refaites le test de bout en bout après chaque changement de manifeste ou de scopes. Le panorama des outils pour agents IA aide à replacer Slack parmi les surfaces de livraison plutôt que parmi les moteurs d'action métier.

Définir les accès et le routage

Une connexion fonctionnelle n'est pas encore une politique sûre. Décidez :

• si les messages directs sont ouverts, limités ou soumis à pairing ;
• quels canaux sont autorisés ;
• si le bot doit être mentionné dans un canal ;
• quel agent reçoit les messages d'une équipe ou d'un canal ;
• quelles actions Slack sont permises.

Privilégiez les identifiants Slack stables plutôt que les noms visibles. Les noms peuvent changer et produire un routage ambigu. Pour retrouver une cible :

openclaw channels resolve --channel slack "#agents-ia"

Vous pouvez ensuite utiliser un binding pour router un workspace ou un canal vers un agent spécialisé. Le Gateway reste la source de vérité pour ces sessions. Dans un canal partagé, l'obligation de mention évite que chaque conversation ambiante déclenche l'assistant.

Pour une notification proactive, utilisez une route explicite et testée. Une automatisation peut livrer son résultat à Slack ; le job doit afficher sa destination résolue avant activation. Un message envoyé ne doit être considéré comme livré qu'après vérification de la réponse du canal ou du journal d'exécution.

Exemple concret

Imaginons une veille concurrentielle exécutée chaque soir. Le bon design n'est pas une classe SlackNotificationSkill, mais une chaîne composée de trois briques :

1. une automatisation OpenClaw déclenche la veille ;
2. l'agent utilise les outils web autorisés et écrit le rapport ;
3. la livraison de l'automatisation cible le canal Slack prévu.

Avant de planifier, lancez la veille manuellement depuis Slack. Vérifiez que l'agent répond dans le bon thread, que le rapport contient des sources et qu'aucun autre canal ne reçoit le résultat. Créez ensuite une automatisation avec une destination explicite et une session isolée si le rapport ne doit pas reprendre le contexte des conversations quotidiennes.

Le message final doit rester court : statut, trois faits utiles, emplacement du rapport et éventuelle action attendue. Les logs détaillés restent dans le système d'exploitation ou le workspace, pas dans le canal d'équipe. Mentionnez une personne uniquement lorsqu'une décision ou un incident exige son attention.

Ajoutez un scénario d'échec reproductible : donnez temporairement une cible inexistante au job de test et vérifiez que l'exécution ne passe pas au vert. Remettez ensuite l'identifiant stable du canal, relancez et confirmez la présence du message dans Slack. Cette lecture du système cible est la preuve de livraison ; une simple réponse générée par l'agent ne suffit pas.

Pour un usage plus large, reliez ce pattern à OpenClaw en production et à l'orchestration des agents.

Bonnes pratiques

• Commencez en Socket Mode. Il évite une surface HTTP publique lorsque vous n'en avez pas besoin.
• Réutilisez le manifeste officiel actuel. Une liste de scopes copiée vieillit vite.
• Gardez les tokens hors des prompts et du dépôt. Utilisez des références de secrets ou l'environnement du Gateway.
• Fermez les canaux par défaut. Ouvrez seulement les espaces et utilisateurs nécessaires.
• Exigez une mention dans les groupes. Cela limite les activations accidentelles et les coûts.
• Préservez les threads. Une réponse dans le mauvais fil disperse le contexte et gêne l'équipe.
• Évitez le flux de logs. Slack doit recevoir des décisions et des exceptions, pas chaque appel d'outil.
• Testez la révocation. Vérifiez que la rotation d'un token ou la désactivation du plugin coupe effectivement l'accès.
• Séparez les frontières de confiance. Des équipes mutuellement hostiles ne devraient pas partager le même Gateway et les mêmes credentials.

Les actions sensibles — publication large, suppression, invitation ou envoi externe — méritent une approbation et une allowlist dédiées.

Questions fréquentes

Slack est-il un skill OpenClaw ?

Non. Slack est un canal implémenté par un plugin officiel. Un skill est un ensemble d'instructions Markdown que l'agent charge pour accomplir une procédure.

Faut-il installer slack-sdk avec pip ?

Non pour l'intégration officielle. Le plugin OpenClaw gère la connexion Slack. Un script Python indépendant peut utiliser Slack, mais il reste externe au système de skills.

Socket Mode ou HTTP ?

Socket Mode convient à la plupart des installations locales ou derrière un pare-feu. HTTP est adapté à un Gateway disposant d'une URL HTTPS publique et d'une architecture d'entrée maîtrisée.

Comment envoyer des notifications sans spammer ?

Livrez uniquement les résultats finaux, échecs et décisions attendues. Regroupez les événements répétitifs dans un digest et gardez les traces détaillées hors de Slack.

Articles liés

Slack apporte une surface de conversation et de livraison, tandis que les skills décrivent les procédures de l'agent. Les ressources suivantes permettent de compléter le canal sans réimplémenter l'API Slack dans un faux module Python.

• Comprendre les skills OpenClaw
• 10 exemples de skills OpenClaw concrets
• Les outils clés d'un agent IA
• Mettre OpenClaw en production
• L'orchestration des agents IA