Construire une application Slack : un manuel du cadrage au lancement

Une équipe parle déjà de votre produit dans un canal. Quelqu'un colle un lien, une autre personne demande ce qu'il est advenu de ce compte, et une troisième ouvre un onglet séparé pour aller vérifier. Cet onglet est l'écart que comble une application Slack. Le travail que vos clients font dans la messagerie toute la journée est le moment d'achat d'une application qui amène votre produit dans la conversation, et la décision d'en construire une commence là, pas avec la plateforme.

Voici un manuel indépendant. PartnerMatch n'est pas affilié à Slack, et rien ici n'est un document officiel de programme. Les exigences de la plateforme, les noms de portées et les critères de revue changent, alors traitez les détails exacts comme des choses à confirmer dans la documentation officielle actuelle plutôt que comme des faits figés. Ce qui ne change pas beaucoup, c'est la forme du travail : décider de l'adéquation, choisir les bonnes surfaces, ne demander que l'accès dont vous avez besoin, passer la revue, et se lister là où les équipes peuvent vous trouver. C'est cette forme que couvre ce guide, dans l'ordre où vous la rencontrez.

Il s'accompagne de nos manuels du cadrage au lancement pour d'autres écosystèmes, le manuel des applications Shopify et la HubSpot App Marketplace, et de notre guide plus large de stratégie de marketplace SaaS, pour que vous puissiez comparer ce qui est commun à toutes les plateformes et ce qui est propre à la construction dans la messagerie.

L'essentiel en 60 secondes

• Décidez d'abord de l'adéquation. Une application Slack est rentable quand vos utilisateurs travaillent déjà dans la messagerie et que votre produit a un moment qui a sa place dans la conversation. Si ni l'un ni l'autre n'est vrai, l'effort peut ne pas être récompensé.
• Choisissez la surface selon la tâche. Bots, slash commands et events sont des outils différents. Commencez par celui qui correspond au flux de travail, pas par tous à la fois.
• Demandez les portées les plus étroites. Chaque portée OAuth que vous demandez est quelque chose qu'un administrateur de workspace et un évaluateur remettront en question. Le moindre privilège est plus facile à approuver et inspire davantage confiance.
• Construisez pour le workspace, pas pour un seul utilisateur. Les jetons, les installations et les données sont cantonnés par workspace, et bien établir ce modèle tôt épargne une reprise pénible.
• Traitez la revue comme des critères d'acceptation. Lisez les exigences actuelles avant de concevoir et construisez en fonction d'elles, pour que la revue soit un non-événement plutôt qu'une course.
• La fiche de l'annuaire est une surface de conversion. Mettez en avant le flux de travail et le résultat, montrez ce que fait l'application dans la messagerie, et rendez le support et la tarification clairs.
• Listé est le début, pas la fin. Les installations viennent de l'activation et du travail après le lancement, pas de l'existence de la fiche.

Étape 1 : décider si une application Slack convient

L'erreur la plus coûteuse est de faire tout ce travail pour une surface qui n'allait jamais faire bouger vos chiffres. Avant tout développement, répondez honnêtement à une question : vos utilisateurs travaillent-ils déjà dans la messagerie, et votre produit a-t-il un moment qui a réellement sa place dans la conversation ?

Quand la réponse est un oui franc, une application de messagerie rejoint les gens là où ils sont déjà. Une équipe qui vit dans les canaux préférera recevoir une notification, lancer une commande rapide ou approuver quelque chose sans quitter la conversation, plutôt qu'ouvrir un autre onglet pour le faire. « Disponible dans l'annuaire » est aussi un petit signal de confiance pour un acheteur prudent. Quand la réponse est non, quand vos utilisateurs ne vivent pas dans la messagerie, ou que votre produit ne touche que de loin le travail qu'ils y font, l'application devient un projet qui coûte des mois et rapporte une poignée d'installations.

Travaillez l'adéquation avant de vous engager :

Si la plupart de vos réponses tombent dans la colonne de droite, le mouvement honnête est de patienter et de réexaminer quand l'adéquation sera plus forte. Nous travaillons ce genre de décision dans construire, acheter ou s'associer et notre guide de stratégie de marketplace. Une application ne vaut un vrai effort que lorsqu'il y a un flux de travail authentique et une vraie demande client derrière elle.

Étape 2 : choisir la bonne surface

Une plateforme de messagerie vous offre plusieurs façons d'apparaître, et elles ne sont pas le même outil. L'erreur courante est de toutes les utiliser dans la première version parce que la documentation les liste toutes. Le meilleur mouvement est de choisir la seule surface qui correspond au flux de travail identifié à l'étape 1, de bien la livrer, et d'en ajouter d'autres seulement quand une vraie tâche l'exige.

Les trois briques dont la plupart des applications partent :

Bots. Un bot est une identité que votre application utilise pour publier des messages, répondre dans les fils, et présenter des éléments interactifs comme des boutons et des menus. C'est la bonne surface quand votre produit doit pousser de l'information dans un canal ou tenir un court échange. Un déploiement s'est terminé, une alerte s'est déclenchée, un client a répondu, et l'application le publie là où l'équipe peut agir. Les bots sont aussi là où vivent les approbations interactives, puisqu'un bouton dans un message est la façon la plus légère possible de laisser quelqu'un confirmer ou rejeter sans quitter la messagerie.

Slash commands. Une slash command est un raccourci tapé qui déclenche votre application à la demande. C'est la bonne surface quand l'utilisateur amorce l'action. Il veut chercher quelque chose, lancer une tâche ou récupérer un statut sans changer de contexte, alors il tape une commande et obtient une réponse immédiate. Les slash commands relèvent du tirage plutôt que de la poussée : l'utilisateur demande, l'application répond.

Events. La surface des events laisse votre application réagir à ce qui se passe dans le workspace, comme un message publié dans un canal où l'application est présente ou une réaction ajoutée. C'est la bonne surface quand votre produit doit répondre à l'activité plutôt qu'attendre d'être appelé. Les events sont puissants et c'est aussi là que s'insinue un accès trop large, car s'abonner à tout est plus facile que s'abonner exactement à ce dont vous avez besoin, donc c'est un endroit où être délibéré.

Une façon rapide de choisir :

Le schéma des boutons interactifs est la même idée d'humain dans la boucle que nous couvrons dans connecteurs et agents : l'application propose, une personne confirme, et seulement alors quelque chose change. Sur une surface de messagerie, cette confirmation est un bouton, ce qui est à peu près l'approbation la plus sans friction qui soit.

Étape 3 : demander les portées les plus étroites

C'est l'étape qui décide de la confiance que vous gagnez et de la fluidité de la revue. Une plateforme de messagerie utilise des portées OAuth pour contrôler ce qu'une application peut lire et faire, et chaque portée que vous demandez est une permission qu'un administrateur de workspace voit à l'installation et qu'un évaluateur remet en question à la soumission. Le principe est le moindre privilège : demandez exactement l'accès qu'utilisent vos fonctionnalités, et rien que vous pourriez utiliser un jour.

Le raisonnement est le même que celui qui rend toute intégration sûre à livrer. Un accès large est une responsabilité que vous portez. Une application qui peut lire chaque message d'un workspace est un risque plus grand, une décision d'installation plus difficile et une revue plus poussée qu'une application qui ne peut publier que dans le seul canal où elle a été ajoutée. Plus la demande est étroite, plus chaque étape ultérieure devient facile, car il y a moins de choses dont quiconque doit s'inquiéter.

Quelques règles gardent les portées honnêtes :

• Reliez chaque portée à une fonctionnalité. Si vous ne pouvez pas pointer la fonctionnalité exacte qu'une portée active, ne la demandez pas. Une portée sans fonctionnalité derrière est une pure responsabilité.
• Préférez la plus étroite de deux options. Là où une plateforme offre une portée plus serrée qui couvre votre besoin, prenez-la plutôt que la plus large, même si la plus large est plus pratique à coder.
• Ajoutez des portées quand les fonctionnalités sont livrées, pas à l'avance. Demander un accès pour un élément de roadmap que vous n'avez pas encore construit, c'est porter un risque pour une fonctionnalité qui n'existe pas. Demandez quand vous la construisez.
• Expliquez le pourquoi à l'installation. Dites à l'administrateur, en langage clair, à quoi sert chaque permission. Un administrateur qui comprend la demande l'approuve ; un administrateur surpris par elle hésite.

La même discipline de moindre privilège apparaît du côté producteur de toute intégration. Notre guide d'une API prête pour les partenaires couvre le cantonnement de l'accès du côté du produit avec lequel on s'intègre, et la logique est identique : accordez le minimum qui fait le travail.

Étape 4 : construire pour le workspace

Le modèle de données d'une application de messagerie s'organise autour du workspace, pas de l'utilisateur individuel, et bien établir cela tôt épargne une reprise pénible à faire tard. Une application est installée dans un workspace, les jetons qu'elle reçoit sont cantonnés à ce workspace, et les données qu'elle peut toucher appartiennent à ce workspace. Construisez comme si chaque installation était son propre locataire, car c'est ce qu'elle est.

En pratique, cela signifie quelques choses. Stockez l'installation et ses jetons par workspace, pour que l'application d'un client ne puisse pas atteindre les données d'un autre. Authentifiez-vous via le flux OAuth standard de la plateforme plutôt qu'en demandant des identifiants que vous détenez vous-même. Gérez proprement le rafraîchissement et la révocation des jetons, puisqu'un administrateur peut retirer votre application à tout moment et votre système doit le remarquer et s'arrêter. Et isolez les workspaces au niveau de la couche de données, pour que la frontière soit imposée dans vos requêtes, pas seulement supposée dans votre code.

Les schémas sous-jacents sont les mêmes que dans toute intégration solide : authentification propre, permissions à portée limitée, et isolation entre locataires. Notre guide sur la gestion de l'authentification dans les intégrations couvre le volet authentification, et l'exigence d'isolation des workspaces est la même discipline de frontière de données que nous couvrons dans la sécurité MCP : les données d'un client ne doivent jamais être atteignables depuis la session d'un autre. Mieux vous respectez ce modèle dès le départ, moins vous rencontrez de constats à la revue, car la plupart des constats remontent à un modèle d'installation qui a traité le workspace comme une réflexion après coup.

Étape 5 : traiter la revue comme des critères d'acceptation

Pour atteindre l'annuaire public, une application passe par une revue, et cette revue est un vrai filtre, pas une formalité. L'erreur est de la traiter comme un examen final que l'on bachote à la fin. Le bon mouvement est de lire les exigences actuelles avant de concevoir et de construire en fonction d'elles comme critères d'acceptation, pour que la revue confirme ce que vous avez déjà fait au lieu de faire surgir des surprises.

Le raisonnement est simple. Les constats découverts à la soumission sont coûteux, car les corriger signifie souvent changer la façon dont l'application gère les jetons, les portées ou les données, ce qui est une reprise par-dessus des fonctionnalités terminées. Les mêmes constats attrapés pendant le développement sont peu coûteux, car vous le construisez bien du premier coup. Vous pliez donc les exigences dans votre définition de « terminé » et vous vérifiez en fonction d'elles au fur et à mesure. C'est la même logique que notre guide de certification d'application sans douleur : la checklist, ce sont des critères d'acceptation, et la satisfaire devrait être un non-événement parce que vous avez construit en fonction d'elle depuis le début.

Les exigences exactes sont à la plateforme de les définir et elles changent, alors confirmez-les dans la documentation officielle actuelle. Les catégories qui importent aux revues sérieuses sont stables :

Deux pratiques rendent la revue fluide. D'abord, préparez des preuves, pas seulement du code qui fonctionne : les évaluateurs veulent comprendre pourquoi vos portées sont celles que vous avez choisies et comment vous gérez les données, ce qui signifie de la documentation, pas seulement une démonstration réussie. Ensuite, faites une auto-revue par rapport aux exigences publiées avant de soumettre, idéalement avec quelqu'un qui n'a pas construit la fonctionnalité, pour que les lacunes évidentes soient attrapées par vous plutôt que par l'évaluateur. Une première soumission propre épargne un aller-retour, et les allers-retours sont là où partent les semaines. Pour le volet ingénierie, les classes courantes de vulnérabilités web et d'API sont bien documentées par l'OWASP, lié à la fin.

Étape 6 : écrire une fiche d'annuaire qui convertit

Passer la revue vous donne le droit de lister. Cela ne vous donne pas d'installations. La fiche de l'annuaire est une surface de conversion, et la plupart d'entre elles sous-vendent l'application en décrivant ce qu'elle est au lieu de ce qu'elle fait pour la personne qui lit.

Mettez en avant le flux de travail et le résultat. Quelqu'un qui parcourt l'annuaire pose une seule question : est-ce que cela rendra une tâche que je fais déjà plus rapide ou meilleure. Répondez-y dès les premières lignes, dans son langage, avant toute liste de fonctionnalités. « Recevez une alerte dans le canal au moment où une affaire se conclut » l'emporte sur « une puissante intégration de messagerie » à tous les coups, car le premier nomme une tâche que l'équipe reconnaît et le second l'oblige à chercher si cela s'applique.

Ce qu'inclut une fiche qui convertit :

• Un titre et un résumé axés sur le flux de travail. Le résultat et la tâche, dans les mots de l'acheteur, pas votre nom interne pour la fonctionnalité.
• Montrez l'application dans la messagerie. Une vraie capture d'écran du bot qui publie ou de la commande qui répond l'emporte sur un graphisme générique. Les gens veulent voir ce qu'ils obtiennent.
• Les portées, expliquées. Soyez transparent sur ce à quoi l'application accède et pourquoi. L'administrateur qui décide d'installer ou non regardera, et une explication claire bâtit la confiance.
• Une tarification honnête et claire. Quel que soit votre modèle, énoncez-le clairement. Un acheteur qui ne peut pas savoir combien cela coûte suppose le pire et passe son chemin.
• De la preuve sociale. Des avis et des clients nommés si vous en avez. Tôt, même une poignée d'avis authentiques fait bouger le prochain acheteur.
• Un support évident. Faites comprendre que quelqu'un est derrière l'application et comment le joindre. Les administrateurs n'installeront pas de logiciel sans propriétaire visible.

Nous approfondissons le texte de fiche dans nos guides pour écrire une fiche de marketplace qui convertit et comment les marketplaces classent les applications. La version courte : la fiche est du texte commercial visant un acheteur précis qui fait une tâche précise, et celles qui convertissent nomment cette tâche et prouvent que l'application la fait.

Étape 7 : générer des installations après avoir listé

On suppose souvent que lister est la ligne d'arrivée et que les installations suivent d'elles-mêmes. Ce n'est pas le cas. Une nouvelle fiche dans un grand annuaire est une tuile parmi tant d'autres, et la découverte seule ne la portera pas. Le travail après le lancement est ce qui transforme une fiche en adoption.

Le premier tour du volant est le plus dur, alors amorcez-le délibérément. Pointez vos propres clients qui utilisent les deux produits vers la fiche pour semer les premières installations. Demandez aux clients satisfaits des avis honnêtes, car les premiers sont ce qui met le prochain administrateur à l'aise. Puis observez ce qui se passe après l'installation : la métrique qui compte n'est pas les installations, c'est les workspaces actifs et retenus, et une application qui s'installe mais n'est jamais utilisée est un risque de churn, pas une victoire.

Les démarches qui génèrent de l'adoption après le lancement :

Nous couvrons le manuel d'après-lancement dans générer des installations après le lancement et la démarche plus large dans notre guide du moteur de vente conjointe. Le fil conducteur, c'est que la fiche est le début du travail, pas sa fin.

Erreurs fréquentes, et comment les corriger

Construire parce que la plateforme est grande, pas parce qu'elle convient. La correction : confirmez que vos utilisateurs travaillent dans la messagerie et que votre produit a un vrai moment dans la conversation avant de vous engager. Une application sans adéquation authentique ni demande est des mois d'effort pour une tuile que personne n'installe.

Utiliser toutes les surfaces à la fois. La correction : choisissez la seule surface qui correspond au flux de travail, bot, slash command ou events, livrez-la bien, et ajoutez-en d'autres quand une vraie tâche l'exige. Une application ciblée est plus facile à construire, à examiner et à expliquer.

Demander plus de portées que vous n'en utilisez. La correction : reliez chaque portée à une fonctionnalité livrée et demandez l'option la plus étroite. Chaque portée superflue est quelque chose sur quoi l'administrateur hésite et que l'évaluateur remet en question, et le moindre privilège est à la fois plus sûr et plus facile à approuver.

Traiter l'installation comme par utilisateur au lieu de par workspace. La correction : construisez le modèle de données autour du workspace, stockez les jetons par installation, et isolez les workspaces au niveau de la couche de données. Se tromper là-dessus est coûteux à corriger après le lancement.

Traiter la revue comme un examen final. La correction : lisez d'abord les exigences actuelles et construisez en fonction d'elles comme critères d'acceptation. Les constats attrapés pendant le développement sont peu coûteux ; les constats attrapés à la soumission sont une reprise sur des fonctionnalités terminées.

Supposer que les installations suivent la fiche. La correction : semez des installations auprès des clients existants, recueillez des avis, instrumentez l'activation, et relancez les installations bloquées. La découverte seule ne portera pas une nouvelle tuile dans un annuaire encombré.

FAQ

Est-ce un guide officiel de Slack ? Non. PartnerMatch est indépendant et non affilié à Slack, et ceci n'est pas un document officiel de programme. Utilisez-le pour comprendre la forme du travail, et confirmez les portées, exigences et étapes de revue exactes dans la documentation officielle actuelle, qui peut changer sans préavis.

Devrais-je construire un bot, une slash command, ou utiliser les events ? Commencez par celui qui correspond à votre flux de travail. Un bot sert à pousser de l'information et des actions interactives dans un canal, une slash command sert aux recherches et tâches amorcées par l'utilisateur, et les abonnements aux events servent à réagir à l'activité du workspace. La plupart des applications commencent par une seule surface qui convient à la tâche et n'en ajoutent d'autres que quand un vrai flux de travail l'exige.

Comment fonctionnent les portées OAuth et combien devrais-je en demander ? Les portées contrôlent ce que votre application peut lire et faire, et vous devriez demander le moins de portées qui couvrent vos fonctionnalités livrées. Reliez chaque portée à une fonctionnalité précise, préférez l'option la plus étroite quand elle existe, et ajoutez des portées quand vous construisez la fonctionnalité plutôt qu'à l'avance. Le moindre privilège est plus facile à approuver pour un administrateur et à faire passer pour un évaluateur.

Que vérifie réellement la revue ? Les critères exacts sont à la plateforme de les définir et ils changent, alors confirmez-les officiellement. Les catégories sont stables : portées au moindre privilège, OAuth et gestion des jetons sécurisés, gestion des données et isolation des workspaces sécurisées, gestion correcte des secrets, comportement conforme à la description, et une fiche exacte. Traitez-les comme des critères d'acceptation en fonction desquels vous construisez, et préparez des preuves, pas seulement une démonstration qui fonctionne.

Dois-je être partenaire pour lister dans l'annuaire ? Lister implique généralement des étapes de programme que la plateforme définit et met à jour, alors confirmez les exigences actuelles dans la documentation officielle plutôt que de supposer. Le travail de ce guide, adéquation, choix de surface, portées, développement, revue et fiche, s'applique quelle que soit la structure exacte du programme le jour où vous commencez.

En quoi est-ce différent de lister sur d'autres marketplaces ? La forme est la même sur les plateformes sérieuses : décider de l'adéquation, construire sur le modèle de la plateforme, demander le moindre privilège, passer une revue, écrire une fiche qui convertit, et générer des installations après le lancement. Les spécificités diffèrent dans les surfaces disponibles, les portées et exigences exactes, et le format de la fiche. Comparer nos manuels Shopify et HubSpot à celui-ci montre ce qui est commun et ce qui est propre à la plateforme.

Pour aller plus loin

• Portail API de Slack pour créer une application et voir les surfaces, portées et réglages disponibles aux développeurs.
• Slack Marketplace pour voir comment les applications listées sont présentées aux équipes qui choisissent quoi installer.
• OWASP pour les classes courantes de vulnérabilités web et d'API qu'une revue de sécurité teste, utile sur le volet ingénierie de la préparation à la revue.

La version courte

Construire une application Slack vaut un vrai effort quand vos utilisateurs travaillent déjà dans la messagerie et que votre produit a un moment qui a sa place dans la conversation, et c'est un détour coûteux quand cette adéquation manque. Choisissez la surface selon la tâche : un bot pour pousser de l'information et des actions interactives, une slash command pour les tâches amorcées par l'utilisateur, les events pour réagir à l'activité, et livrez-en une bien avant d'en ajouter d'autres. Demandez les portées OAuth les plus étroites qui couvrent vos fonctionnalités livrées, car chaque permission superflue est quelque chose qu'un administrateur et un évaluateur remettent en question. Construisez pour le workspace, avec les jetons et les données isolés par installation. Traitez la revue comme des critères d'acceptation en fonction desquels vous construisez dès le premier jour, et préparez des preuves de moindre privilège et de gestion des données sécurisée plutôt qu'une simple démonstration. Écrivez une fiche qui met en avant le flux de travail et montre l'application dans la messagerie, puis faites le travail d'après-lancement pour générer des installations, car la fiche est le début du travail, pas sa fin. Et parce que les spécificités de la plateforme changent, confirmez les portées et exigences exactes dans la documentation officielle actuelle, puisque ceci est un manuel indépendant, pas un manuel officiel.

Si vous voulez de l'aide pour décider si une application de messagerie convient, choisir les surfaces, ou transformer une fiche en adoption, un Partner Audit passe en revue votre produit, votre surface d'intégration et votre potentiel de marketplace, puis vous remet un plan concret de ce qu'il faut construire et des écosystèmes à poursuivre.