Slack ouvre ses canaux aux agents, mais les administrateurs gardent la clé

Dans un billet publié le 1er octobre 2026, Slack présente les conversations dans les canaux comme un contexte commun aux employés, aux agents et aux applications ; Rob Seaman, vice-président exécutif et directeur général de Slack, déclare à propos des données, processus et agents Salesforce qu’ils sont « available in Slack the same way you'd talk to a teammate ». L’entreprise veut faire passer l’agent de l’échange individuel avec un chatbot à une contribution que l’équipe peut voir et reprendre là où elle travaille.

À Dreamforce, TechRadar a rapporté que la possibilité de mentionner Slackbot dans un canal était encore annoncée comme prochaine, sans date de sortie précisée. La documentation d’administration de Slack décrit le parcours pour découvrir des agents, demander l’installation de leur application et régler leur affichage. L’ouverture des canaux dépend donc des agents effectivement installés et des choix de chaque organisation.

Du chatbot individuel à l’agent dans le canal

Dans une conversation privée, la réponse d’un chatbot reste attachée à la personne qui l’a demandée. Dans un canal, les échanges antérieurs, l’intervention de l’agent et les réactions de l’équipe peuvent se retrouver au même endroit. Cette visibilité est au cœur de la proposition de Slack : une réponse devient un élément du travail collectif, que les membres peuvent discuter, retrouver et prolonger sans devoir se faire transférer un dialogue privé.

Le contexte partagé est aussi une ressource pour l’agent. Le serveur Model Context Protocol de Slack et son API de recherche en temps réel permettent de relier des agents aux fils de discussion et aux décisions utiles. La portée de cette connexion dépend des droits accordés : le fait qu’une conversation existe dans Slack ne donne pas automatiquement à n’importe quel agent accès à son contenu. Pour les données Salesforce accessibles depuis Slack, les autorisations, la sécurité au niveau des champs et les règles de partage existantes restent applicables.

Slackbot occupe une place différente de celle des agents spécialisés : il peut recevoir une demande en langage courant et l’orienter vers un outil connecté. Dans le scénario du canal, le groupe verrait la réponse au lieu de laisser le résultat dans un échange privé. La possibilité de l’y mentionner, présentée à Dreamforce, reste toutefois une fonction annoncée pour plus tard. Elle ne doit pas être confondue avec le parcours d’installation des applications d’agents déjà documenté.

Le catalogue ouvre une demande, pas un droit d’installation

L’onglet « Agents & tools » de la barre latérale regroupe les applications, les agents et les automatisations accessibles sur ordinateur. Il distingue notamment les agents populaires de ceux déjà installés dans l’espace de travail. Pour en chercher un autre, un membre passe par AgentExchange, sélectionne une application et arrive sur le Slack Marketplace. Cette navigation rend les possibilités visibles, mais elle ne préjuge pas de la décision d’installation.

Après le bouton « Add to Slack », l’utilisateur arrive à l’étape d’autorisation. Si les règles de l’organisation le permettent, il peut accepter les permissions demandées ; sinon, il doit accompagner sa requête d’un message à l’administrateur et utiliser « Submit Request ». La demande ne vaut pas approbation. Le contrôle administratif intervient donc avant que l’application fournissant l’agent ne rejoigne l’espace de travail, même si cet agent était facile à trouver dans le catalogue.

Cette séquence explique la différence entre un agent repéré par un salarié et un agent utilisable par son équipe. Le Marketplace présente une application ; l’installation détermine si elle entre dans l’environnement de travail ; ses permissions définissent ensuite ce qu’elle peut faire. Aucun de ces passages ne découle de la seule présence d’une fiche dans AgentExchange. Une équipe peut ainsi identifier un agent adapté à sa tâche sans que sa politique d’applications autorise immédiatement son ajout.

Un second réglage décide de ce que les membres voient

L’installation ne clôt pas le parcours. Par défaut, les expériences d’agent ou d’assistant apportées par une application apparaissent en haut de Slack. Les propriétaires et administrateurs peuvent ouvrir les paramètres de cette application et régler l’expérience correspondante sur « Enabled » ou « Disabled ». Ce choix porte sur son affichage aux membres ; il intervient après la décision d’autoriser l’application.

Sur les offres Pro et Business+, la gestion passe par les applications installées accessibles depuis les outils d’administration et le Marketplace. Dans une organisation Enterprise, elle passe par les paramètres de l’organisation, puis par les intégrations et les applications installées. Le réglage Enterprise s’applique aux espaces de travail où l’application concernée est installée. Cette commande est proposée sur les offres payantes aux propriétaires et administrateurs des espaces ou des organisations.

Masquer une expérience d’agent ou d’assistant dans l’interface ne revient pas à retirer l’application ni à revoir ses permissions. Des membres peuvent également interagir avec certains agents depuis l’onglet d’accueil de leur application. L’administrateur qui modifie l’affichage change donc la manière dont les membres trouvent l’agent sans, par ce seul geste, trancher la question de sa présence ou de ses droits dans l’espace de travail.

À lire aussi :

• Le marketing créateur gagne 33 % de budget, mais ses systèmes décrochent
• ARE ou ARCE en 2026 : 60 % en capital, mais pas les mêmes droits
• FreeIPA : un client LDAP anonyme peut obtenir les droits administrateur