Relier votre logiciel métier à Slack : messages, événements et validations

Que permet l'API de Slack, concrètement ?

L'API de Slack permet à un logiciel métier d'écrire dans des canaux, de répondre dans des fils, de lire l'historique et d'être prévenu quand un utilisateur agit. Chaque mécanisme a son sens et ses contraintes.

L'authentification suit OAuth 2.0, dans la version 2 du parcours Slack : la personne qui installe l'application est redirigée vers l'adresse d'autorisation de Slack avec la liste des droits demandés (scopes), Slack renvoie un code valable dix minutes, et le logiciel l'échange par oauth.v2.access contre un jeton de bot (préfixe xoxb dans les exemples de Slack) et, si besoin, un jeton utilisateur (préfixe xoxp). Selon Slack, ces jetons n'expirent pas et peuvent être révoqués quand ils ne servent plus ; avec la rotation des jetons, le jeton d'accès s'échange contre un jeton expirant et un jeton de renouvellement.

Quelles limites de débit Slack applique-t-il ?

Slack applique ses limites par méthode, par espace de travail et par application. Trois chiffres comptent pour une intégration d'entreprise.

• Publication : la référence de chat.postMessage indique qu'une application peut en général publier un message par seconde dans un canal donné, avec un plafond de plusieurs centaines de messages par minute pour l'espace de travail et une tolérance généreuse aux rafales.
• Lecture de l'historique : le journal des modifications de Slack du 29 mai 2025 fixe, pour les nouvelles applications commercialisées hors Slack Marketplace, une requête par minute et quinze messages par appel sur conversations.history et conversations.replies. Les applications internes conservent plus de 50 requêtes par minute et jusqu'à 1 000 messages par appel.
• Socket Mode : une application peut maintenir jusqu'à dix connexions WebSocket simultanées, et les applications en Socket Mode ne sont pas admises sur le Slack Marketplace public.

La conséquence pratique est simple : pour relier le logiciel d'une PME à son propre Slack, on crée une application interne à l'espace de travail de l'entreprise. Elle échappe aux restrictions visant les applications distribuées, et elle reste la propriété du client.

Cinq flux Slack qui font gagner du temps dans une PME

1. La grosse commande signalée au bon canal. Le logiciel de gestion enregistre une commande au-dessus d'un seuil ; il publie dans le canal des ventes le client, le montant et un lien vers la fiche. Il garde l'identifiant du message, puis ajoute dans le même fil la confirmation d'expédition et le numéro de suivi : toute l'histoire de la commande tient en un fil.
2. La validation en un clic. Un devis dépasse la remise autorisée ; le responsable reçoit un message direct avec deux boutons, Valider et Refuser. Son clic revient au logiciel par les fonctionnalités interactives de Slack, qui enregistre la décision, l'heure et l'identité Slack du valideur, puis débloque l'envoi du devis.
3. L'alerte qui ne se perd pas. Une machine passe en défaut ou un stock tombe sous le minimum. Le message part dans le canal de la maintenance ou des achats ; le premier qui répond « je prends » dans le fil est enregistré comme responsable dans le logiciel, et l'alerte disparaît du tableau des actions ouvertes.
4. Le point du matin. Chaque jour ouvré, le logiciel publie un résumé : livraisons prévues, retards, factures relancées par le flux de relance des impayés.
5. La question posée à l'application. Un commercial mentionne l'application dans un canal avec une référence d'article ; Slack transmet l'événement, le logiciel lit le stock et répond dans le fil.

Slack sert ici de point de notification et de décision, jamais de base de données. Si les mêmes informations sont aujourd'hui recopiées à la main d'un outil à l'autre, notre page pour éliminer les doubles saisies décrit l'approche d'ensemble.

Comment se déroule l'intégration, étape par étape ?

1. Choisir les flux et les canaux : quel événement du logiciel produit quel message, pour qui, et quelle action est attendue en retour.
2. Créer l'application dans l'espace de travail du client, avec un compte administrateur de l'entreprise, pour qu'elle ne dépende d'aucun prestataire.
3. Demander le minimum de droits : chat:write pour publier, chat:write.public seulement s'il faut pouvoir publier dans tous les canaux publics, et rien de plus.
4. Choisir le mode de réception : une URL publique, que Slack valide en envoyant un défi (url_verification) auquel le serveur répond, ou le Socket Mode quand le serveur est derrière un pare-feu et ne peut pas être joint depuis Internet.
5. Tester dans un espace de travail de développement, distinct de celui où travaillent les équipes, puis installer en production.
6. Mettre en service sous observation : messages envoyés, refusés ou rejoués sont suivis dans le journal.

Le service qui fait le lien entre le logiciel et Slack suit la même architecture que nos autres connexions, décrite sur la page connecter ses logiciels par API.

Signatures, doublons, données personnelles : les points d'attention

• Vérifier chaque requête entrante. Slack ajoute les en-têtes X-Slack-Signature et X-Slack-Request-Timestamp. Le serveur recalcule une empreinte HMAC SHA-256 de la chaîne « v0:horodatage:corps brut » avec le Signing Secret de l'application et compare. L'exemple de Slack rejette toute requête dont l'horodatage s'écarte de plus de cinq minutes, ce qui bloque le rejeu. L'ancien jeton de vérification est déprécié.
• Accuser réception tout de suite. L'Events API attend une réponse HTTP 200 ; Slack retente l'envoi en cas d'échec. Le serveur répond donc d'abord, traite ensuite en arrière-plan, et ignore un événement dont l'identifiant (event_id) a déjà été traité.
• Mettre les envois en file. Une rafale de cinquante alertes ne doit pas partir d'un bloc : une file d'attente respecte le rythme d'un message par seconde et par canal et rejoue les envois refusés.
• Ranger les secrets. L'URL d'un webhook entrant vaut un mot de passe : Slack indique rechercher et révoquer les secrets divulgués, par exemple dans un dépôt public. Jetons et Signing Secret vont dans un coffre de secrets, jamais dans le code.
• Limiter les données personnelles. Un message Slack est lu par tout le canal et conservé selon la politique de l'espace de travail. On n'y envoie que le nécessaire, avec un lien vers le logiciel pour le détail, et le flux est inscrit au registre des traitements.

Webhook simple, outil d'automatisation ou développement ?

Pour une notification à sens unique, un webhook entrant suffit souvent : si votre logiciel sait appeler une URL avec un JSON, il publie dans Slack sans développement lourd. Les outils d'automatisation sans code, comparés dans notre page n8n, Make ou Zapier, couvrent aussi les flux simples entre logiciels en ligne connus.

Le développement se justifie quand l'échange va dans les deux sens (validation, prise en charge d'une alerte), quand il faut relier l'identité Slack d'un salarié à son compte dans le logiciel, quand la logique dépend de vos règles de gestion, ou quand le logiciel métier est un outil spécifique sans connecteur. Si votre entreprise travaille plutôt sous Microsoft, la même réflexion vaut pour Microsoft Teams.

Ce que vous récupérez en fin de projet

L'application Slack est enregistrée dans votre espace de travail, sous votre compte. Le service de liaison est écrit en technologies standard (Node.js, PostgreSQL pour le journal), déposé dans votre dépôt de code et hébergé sur votre infrastructure. Vous recevez la liste des droits demandés et leur justification, la fiche de chaque flux, la procédure de renouvellement des secrets et un écran de suivi des messages envoyés ou en échec. Le code vous appartient au paiement intégral ; notre façon de construire ces services est présentée sur la page API et intégrations.