Intégration API Slack
Nous développons votre connecteur Slack
Nous branchons Slack à votre produit : l'alerte part du dossier métier, le bouton Relancer écrit dans l'ERP, la slash command répond sans ouvrir un second outil.
- Équipe produit senior
- connecteurs Slack en production
- du cadrage au monitoring
À quoi sert l'API Slack et pourquoi l'intégrer dans votre plateforme ?
Slack est l'outil de communication interne de référence pour les équipes techniques et produit. Son API permet à votre application d'envoyer une notification dans le bon canal, de créer un fil contextuel, ou de recevoir une commande et d'écrire dans votre logiciel. On l'intègre pour que tout cela vive dans votre produit : alerte née du dossier métier sans portail parallèle, bouton Relancer qui pose l'événement dans l'ERP, slash command qui répond depuis le même SI, canal projet ouvert à la création d'affaire. Slack reste le canal ; votre application reste la source de vérité.
Ce que Slack change dans votre plateforme
Alerte native depuis le dossier métier
Facture J+7, paiement échoué, colis bloqué : le canal reçoit le dossier avec le lien profond. L'équipe n'apprend plus l'incident dans un e-mail oublié.
Bouton Relancer qui écrit dans l'ERP
Le clic depuis Slack pose l'événement métier. Pas de second process : l'action vit dans votre SI, Slack n'est pas la source de vérité.
Slash command sans quitter le canal
/dossier renvoie le statut en éphémère. Personne n'ouvre un outil parallèle pour un numéro de commande.
Canal projet ouvert avec l'affaire
À la création du dossier, le canal invite les bons interlocuteurs et pose le lien. L'accueil RH suit le même schéma, checklist comprise.
Ce que ça change dans votre produit
La technique au service d'un résultat mesurable : alerte native, action vers l'ERP, même SI.
Le produit notifie là où l'équipe est déjà
Devis signé, paiement échoué, colis bloqué : le message porte le dossier. Plus de centre de notification parallèle.
Le clic dans Slack écrit dans le métier
Slash command, raccourci, modal : relancer, valider, créer un ticket. L'ERP se met à jour pendant le clic.
L'ops n'ouvre plus un second outil
Le statut commande ou le lien dossier répond dans le canal. Le parcours reste dans votre plateforme.
Le canal projet naît avec l'affaire
À l'ouverture du dossier, les interlocuteurs et le lien sont déjà là. Pas de création manuelle à côté du SI.
Comment nous livrons votre connecteur Slack
Cadrage
Où Slack entre dans votre produit : alertes, boutons, slash commands, canaux projet. Workspaces, scopes, HTTP ou Socket Mode. Tranché avant de coder.
Prototype
Une app recette branchée sur un événement réel de votre produit et une slash command qui écrit déjà dans l'ERP. Vous voyez le parcours, pas une démo de webhook.
Développement
Connecteur branché sur vos alertes et vos actions métier. HMAC v0 sur corps brut, ACK immédiat, file, dédup event_id, Retry-After.
Monitoring
Taux d'ACK, 429, app_rate_limited, signatures rejetées. Rotation du Signing Secret et app recette / prod séparées.
Ce que l'API apporte à votre plateforme
- Pousser l'alerte depuis le produit
- chat.postMessage et chat.update alimentent le canal avec le dossier. Burst d'alertes via la Web API, pas l'incoming webhook à 1/s.
- Recevoir l'action vers votre SI
- Events API HTTP ou Socket Mode : le clic Relancer, la mention, le message ciblé reviennent dans votre application.
- Slash commands et modales métier
- Une commande dans Slack lit ou écrit dans l'ERP. Ce n'est plus un webhook one-shot collé à un canal.
- Ouvrir le canal au bon moment
- conversations.create et users.lookupByEmail : le canal projet naît avec l'affaire, le bon interlocuteur reçoit le DM.
Le vocabulaire de l'API Slack
- Signing Secret
- Secret HMAC de l'app. Basestring v0:{timestamp}:{corps brut}, en-tête X-Slack-Signature. Parser le JSON puis re-signer échoue. Fenêtre de replay : 5 minutes.
- ACK 3 secondes
- L'Events API exige un 2xx en moins de 3 secondes. Moins de 5 % d'ACK sur 60 minutes (et plus de 1 000 événements/h) : l'abonnement est temporairement coupé. ACK d'abord, file ensuite.
- app_rate_limited
- Plafond de 30 000 livraisons par workspace, par app, par 60 minutes. Au-delà, Slack émet cet événement et cesse de livrer. Ce n'est pas un 429 de la Web API.
- Socket Mode
- Connexion WebSocket sortante, max 10 par app. Permet de prototyper sans URL publique. Le Marketplace impose HTTP. Ce n'est pas le canal de charge.
- Tiers Web API
- Paliers 1 à 4 (et special) par méthode et par workspace, fenêtre à la minute. Le chiffre se lit sur la fiche de chaque méthode, pas dans une table unique.
- event_id
- Identifiant de déduplication. Slack peut retenter (3 retries rapides, Delayed Events jusqu'à 24 h). Sans dédup, un bouton Relancer part deux fois.
Les contraintes réelles de l'API Slack
Le métier n'a pas sa place dans le POST Events
Tout traitement synchrone dans le webhook fait désactiver l'app. ACK 2xx immédiat, persistance, worker. Slack l'écrit noir sur blanc, ce n'est pas une préférence d'architecture.
30 000 événements par heure et par workspace
Un abonnement message sur un grand workspace épuise le quota avant midi. On s'abonne au minimum (app_mention, pas message.* global) et on le dit au cadrage.
Incoming webhook n'est pas chat.postMessage
1 requête par seconde sur le webhook d'un canal. Un burst d'alertes passe par la Web API et une file unique par workspace, avec Retry-After.
Socket Mode ne passe pas le Marketplace
10 connexions, état, recyclage. Utile en recette derrière un firewall. En production distribuée, Slack recommande HTTP, et le Marketplace l'impose.
Incoming webhook ou Web API ?
Deux façons de poster dans Slack. Le bon choix dépend du volume et de l'interactivité, pas de la facilité du premier message.
| Critère | Web APIchat.postMessage | Incoming webhook1 req/s |
|---|---|---|
| Débit documenté | Tier de la méthode, par workspace | 1 requête par seconde |
| Burst d'alertes | File + Retry-After | 429 immédiat au-delà de 1/s |
| Mise à jour d'un message | chat.update | Non, un nouveau post |
| Boutons et modales | Interactivity native | Affichage seulement |
| Cible | Canal, DM, selon scopes | Le canal du webhook |
| Auth | OAuth, jeton xoxb- | URL secrète du canal |
| Le bon cas | Produit, alerting, actions | Un canal, faible volume |
Le webhook d'un canal reste utile pour un prototype. Dès que Slack devient une action dans votre produit (burst, bouton, plusieurs canaux), on passe à la Web API. La file sortante est unique par workspace dans les deux cas.
Ce que nous mesurons sur une intégration Slack
Les autres outils de productivité
Si Slack n'est pas le canal d'action de votre produit, ces options se discutent au cadrage.
SlackNous développons votre connecteur SlackCette page
JiraLe ticket, quand l'alerte Slack doit devenir un dossier suivi.
NotionLa base et le wiki, quand l'équipe écrit encore à la main.
AirtableLe tableur structuré, back-office rapide avant un vrai métier.
MetabaseNous développons votre connecteur MetabaseOn combine Slack avec
La stack autour de Slack quand on le branche dans un produit ou un ERP.
Slack : vos questions
On la branche sur vos touchpoints produit : alerte depuis le dossier, bouton qui écrit dans l'ERP, slash command, canal à l'ouverture d'affaire. Techniquement : app Slack dédiée (recette et prod séparées), scopes minimaux, Signing Secret en coffre. Handler Events en ACK 2xx sous 3 secondes, métier en file, dédup event_id. File sortante unique par workspace pour chat.postMessage, Retry-After, incoming webhook réservé au faible volume. La partie sensible n'est pas l'appel API, c'est le parcours produit, la signature HMAC et le plafond de 30 000 livraisons par heure.
L'incoming webhook poste dans un canal, à 1 requête par seconde, sans mise à jour de message ni bouton. L'API Slack (Web API plus Events API) authentifie un bot OAuth, poste et met à jour, ouvre des canaux, répond à une slash command, et reçoit les événements signés. Un burst de 200 alertes passe par chat.postMessage et une file, pas par l'URL d'un canal. Le webhook reste un raccourci de prototype. Dès que Slack devient une action dans votre produit, on parle Web API.
Socket Mode (WebSocket, 10 connexions max par app) sert à prototyper derrière un firewall, sans URL publique. HTTP, avec challenge de vérification, est le canal de production : ACK sous 3 secondes, retries, Delayed Events, et c'est celui qu'impose le Marketplace. Nous commençons parfois en Socket Mode pour une démo interne, puis basculons HTTP avant d'ouvrir l'app à des workspaces clients. Le même Bolt gère les deux, à condition que le métier soit déjà dans une file, pas dans le handler.
Un premier flux utile, typiquement l'alerte métier depuis votre produit vers un canal avec signature et ACK corrects, se livre en deux à trois semaines. Une chaîne complète avec boutons vers l'ERP, slash command, création de canal, plusieurs workspaces et Marketplace demande plutôt six à huit semaines. La durée dépend surtout des touchpoints à brancher, des scopes et de la règle métier derrière chaque action. Nous cadrons le périmètre en amont et donnons une estimation ferme avant de commencer.
En ne s'abonnant pas à message.* sur un workspace de plusieurs milliers de personnes. On cible app_mention, les événements d'app et les canaux utiles. On ACK vite pour ne pas entrer dans la zone des 5 % d'échec. Côté sortie, incoming webhook à 1/s est un autre plafond : le burst passe par la Web API. Depuis mai 2025, les apps distribuées hors Marketplace subissent des limites plus strictes. Le cadrage liste les événements, estime le volume, et pose une alerte sur app_rate_limited avant la mise en production.
Un projet d'intégration Slack ?
Parlons-en. 30 minutes pour cadrer où Slack entre dans votre plateforme (alerte, action ERP, slash command) et vous dire franchement ce qui tient aux quotas.
Parler de mon projet Slack