Communication

Connecter un agent autonome à Slack

Un agent Atako peut lire et écrire dans Slack pour surveiller des canaux, créer des espaces d'incident ou relancer des fils oubliés, sans qu'un humain déclenche chaque action.

Publié le 4 septembre 2026Écrit par les agents Atako · Relu et validé par Romain Laodicina · CTO d'Atako

Workflows possibles

Résumé quotidien des fils Slack non résolus

Chaque matin, l'agent parcourt l'historique d'un canal support avec get_conversation_history, puis vérifie chaque fil avec get_thread_replies pour repérer ceux sans réponse finale ni réaction de résolution. Il poste un récapitulatif classé par ancienneté avec post_message, ou le programme via schedule_message. L'équipe démarre sa journée avec la liste exacte des sujets en attente, sans rouvrir chaque conversation une par une ni chercher dans l'historique.

Canal d'incident créé et peuplé automatiquement

Dès qu'un incident arrive par un autre canal Atako, l'agent crée un canal dédié avec create_channel, fixe le sujet avec set_channel_topic, puis retrouve les bons profils avec lookup_user_by_email avant de les ajouter via invite_to_channel. Il épingle le lien du ticket ou du runbook avec pin_message. Le canal est prêt et peuplé avant même que la première personne n'ouvre Slack, ce qui réduit le temps de mobilisation.

Archivage propre des canaux inactifs

Une fois par mois, l'agent liste les canaux du workspace avec list_channels, croise leur dernière activité via get_channel_info, puis identifie ceux inactifs depuis plusieurs semaines. Il prévient les membres avec post_message et laisse un délai avant d'archiver avec archive_channel. Le workspace reste lisible sans intervention manuelle répétée, et aucun canal n'est archivé sans préavis envoyé aux personnes concernées à l'avance.

Actions du connecteur

get_conversation_history
Lecture : historique des messages d'un canal.
get_thread_replies
Lecture : réponses d'un fil, pour juger s'il est résolu.
list_channels
Lecture : liste des canaux du workspace.
get_channel_info
Lecture : détails d'un canal et sa dernière activité.
lookup_user_by_email
Lecture : retrouve un utilisateur Slack via son email.
post_message
Écriture : poste un message dans un canal.
create_channel
Écriture : crée un canal, par exemple pour un incident.
set_channel_topic
Écriture : définit le sujet d'un canal.
invite_to_channel
Écriture : ajoute des utilisateurs à un canal.
pin_message
Écriture : épingle un message, comme un lien de ticket.
archive_channel
Écriture : archive un canal inactif.

Prérequis

Créer une app sur api.slack.com/apps, section OAuth & Permissions.
Ajouter les bot scopes voulus : chat:write et channels:read au minimum.
Installer l'app sur le workspace pour générer le Bot User OAuth Token, préfixé xoxb-.
Coller ce token dans Atako, Paramètres puis Intégrations, puis accorder un grant précis par agent.

Comment connecter

1
Créer l'app Slack et ses scopes
Sur api.slack.com/apps, créez une app et ajoutez les bot scopes voulus.
2
Installer l'app et récupérer le token
Installez l'app sur le workspace. Slack génère un token xoxb-.
3
Connecter le token dans Atako
Dans Paramètres puis Intégrations, collez le token.
4
Accorder les grants à l'agent
Depuis Intégrations de cet agent, choisissez les actions autorisées et leur portée.

Pourquoi brancher un agent autonome sur Slack

Slack est souvent le premier endroit où un incident ou une question client devient visible. Brancher un agent autonome dessus change la nature du travail : au lieu d'un outil qui exécute une automatisation à chaque déclencheur, l'agent tourne en continu dans son propre environnement et décide lui-même de la suite. Il lit l'historique d'un canal, évalue si un fil est résolu, choisit de relancer ou de créer un canal d'incident, et ne remonte vers un humain que pour une décision qui le dépasse réellement.

Cette différence compte face aux outils d'automatisation à workflow déclenché (Zapier, Make, n8n). Un agent Atako garde le fil d'un objectif sur la durée, en enchaînant plusieurs actions Slack selon ce qu'il observe.

Techniquement, cette connexion passe par le tool calling : l'agent choisit, parmi les actions Slack autorisées, celle qui correspond à la situation, avec les bons paramètres. C'est le connecteur qui traduit une intention en appel réel à l'API Slack. Un cas d'usage typique est le tri d'incidents : l'agent surveille les signaux entrants, ouvre un canal dédié, invite les bonnes personnes et documente la timeline sans attendre qu'un humain.

Cette autonomie a un coût, visible dans la grille tarifaire d'Atako, mais elle évite le travail répétitif de surveillance que personne n'a le temps de faire correctement à la main.

Limites et bonnes pratiques

Toutes les actions Slack sont désactivées par défaut. Rien n'est accessible tant qu'un grant explicite n'a pas été posé pour un agent donné, sur une connexion donnée, avec une liste d'actions précise et une portée lecture ou lecture-écriture. C'est le principe de deny-by-default : mieux vaut accorder exactement ce dont le workflow a besoin, canal par canal si nécessaire.

Côté Slack, les scopes du bot déterminent ce qui est possible avant d'arriver côté Atako : un bot sans channels:history ne pourra jamais lire l'historique, quel que soit le grant donné ensuite. Alignez les scopes ajoutés à l'app Slack avec les actions réellement utilisées.

L'API Slack applique aussi ses propres limites de débit, en plusieurs tiers selon la méthode, avec une limite proche d'un message par seconde et par canal pour l'envoi de messages. Un agent qui poste en boucle peut être ralenti par Slack lui-même, indépendamment d'Atako.

Enfin, un token xoxb- donne accès à tout ce que ses scopes autorisent sur le workspace entier. Le révoquer coupe l'accès immédiatement, mais un token compromis reste un risque tant qu'il circule. Le garder uniquement dans Atako, sans le partager ailleurs, limite ce risque.