L’API Slack Code est désormais généralement disponible sur toutes les offres Slack

Le 28 octobre 2026, Slack a rendu l’API Slack Code généralement disponible sur toutes ses offres, ouvrant à l’agent de n’importe quel développeur le système de canaux de code lancé en août 2026. Dans un article publié sur le blog des développeurs de Slack, l’entreprise a indiqué que plus de 150 clients et partenaires lui avaient demandé d’y accéder pour créer des expériences de canaux de code destinées à leurs propres agents, une possibilité auparavant réservée à une poignée de partenaires du lancement.

Slack a lancé Slack Code en août avec des partenaires tels qu’Anthropic, Cognition, GitHub et Vercel ; l’annonce du lancement citait également OpenAI et indiquait que ChatGPT serait bientôt disponible. Un canal de code est un espace dédié qu’un agent ouvre pour une tâche précise, où se trouvent déjà les bonnes personnes, le contexte et le plan ; une fois le travail terminé, le canal est archivé automatiquement, mais reste consultable. Lors du lancement, Slack a indiqué que plus de 70 % des canaux de code sont créés puis fermés en moins d’une journée, de l’idée à la fusion de la demande de modification.

Utilisez votre propre agent

Maintenant que l’API est généralement disponible, tout développeur peut faire ouvrir un canal de code par un agent, y ajouter les personnes et les fichiers concernés, publier des mises à jour au fil de son travail, puis archiver le canal une fois la tâche terminée. Slack a indiqué que les développeurs disposent des mêmes fonctionnalités de base que celles utilisées par les partenaires du lancement, qu’ils créent un agent maison pour une entreprise ou un nouvel agent destiné à la place de marché Slack.

Selon Slack, intégrer auparavant des agents de programmation à Slack impliquait de faire passer leurs résultats par des fils de discussion classiques et des messages directs, des espaces vite à l’étroit dès qu’un agent devait joindre un fichier journal volumineux, proposer un diff de code de 50 lignes ou exécuter un plan en plusieurs étapes. Slack a ajouté que les entreprises soumises à des exigences de sécurité strictes ne pouvaient pas du tout utiliser d’agents tiers prêts à l’emploi.

L’entreprise explique que l’API ouvre la voie à trois possibilités : des agents qui travaillent au vu de tous en créant leur propre canal de code lorsqu’une demande mérite un espace dédié ; des agents que toute une équipe peut orienter grâce aux marque-pages et à un historique complet de l’exécution ; et des agents auxquels les entreprises peuvent faire confiance, avec la conformité des messages intégrée, ainsi que les contrôles d’espace de travail et les limites de données que les administrateurs utilisent déjà. Les API peuvent afficher des diffs de code, des aperçus HTML et les étapes de réflexion, tandis que Slack gère le reste de l’interface. Slack a précisé qu’il reste une plateforme indépendante des agents : les équipes peuvent donc changer d’agent ou de modèle par la suite tout en continuant à travailler au même endroit.

Slack a indiqué que GitHub Copilot ouvre un canal de code dédié dans 30 % de ses sessions d’agent. Tim Hunter, ingénieur principal chez GitHub, a déclaré que GitHub intègre les interactions avec Copilot auxquelles les utilisateurs sont déjà habitués dans l’espace où ils effectuent le reste de leur travail. Mael Kerichard, ingénieur logiciel chez Mistral, a expliqué que l’API semblait conçue pour les agents d’IA, soulignant sa flexibilité, sa simplicité de configuration et l’étendue de ses fonctionnalités.

Selon Slack, la gouvernance est intégrée : un agent hérite des autorisations et des contrôles d’administration du canal dans lequel il travaille, sans qu’il soit nécessaire pour les développeurs de créer un modèle d’accès distinct ni pour l’équipe informatique de configurer quoi que ce soit de nouveau. Une personne peut approuver chaque modification à fort enjeu, et l’historique des actions de l’agent reste consultable après l’archivage du canal.

Slack illustre ce modèle par une alerte de production à 2 h du matin : un agent d’observabilité personnalisé ouvre un canal de code, récupère les journaux concernés et commence à travailler sur un correctif, tandis que les ingénieurs d’astreinte suivent son travail et le réorientent en cours de tâche. Selon l’entreprise, la même approche s’applique au tri des bogues et aux tâches DevOps, comme les changements de configuration ou les retours à une version antérieure.

Fonctionnement de l’API

La documentation destinée aux développeurs de Slack indique que les applications contrôlent le titre, le statut, la barre de contexte et les onglets d’affichage d’un canal de code au moyen de deux familles de méthodes d’API. Les agents.sessions.* méthodes sont unifiées pour les canaux de code et les fils de session ; un paramètre d’horodatage du fil permet de sélectionner le type de session, et elles nécessitent l’ chat:write autorisation. Les agents.conversations.* méthodes gèrent les tâches propres aux canaux de code et nécessitent l’ code_channels:manage autorisation.

Parmi les méthodes documentées, agents.conversations.* on trouve create, archive (qui peut éventuellement enregistrer un résumé), setProperties, setCommands, setView (qui prend en charge les vues html, diff, block_kit ou canvas), listViews, removeView, getCanvas et setCanvasContent.

Les applications activent les canaux de code en définissant features.code_channels.enabled sur true dans le manifeste de l’application, avec un champ slash_command_urlfacultatif. Lorsqu’un utilisateur mentionne l’application, celle-ci reçoit un événement app_mention et décide de créer un canal de code dédié ou de répondre directement dans le fil. L’appel create prend en paramètre le canal d’origine et l’horodatage du message ; Slack crée alors le canal, reprend ses paramètres de confidentialité et y invite automatiquement le bot.

Selon le modèle d’autorisation documenté, l’appelant doit être le bot agent affecté au canal ou un membre de celui-ci ; sinon, les appels renvoient les erreurs not_agent_channel ou not_authorized. Les canaux de code sont conçus pour être semi-éphémères — un canal par tâche, archivé à la fin de la session — et, une fois archivé, un canal et son historique restent consultables, accessibles à la recherche et susceptibles d’être rouverts.

Outils à venir et mise en route

Slack a indiqué que des améliorations de l’expérience liée aux demandes d’intégration seraient bientôt disponibles : les utilisateurs de GitHub pourront demander des révisions dans Slack, les commentaires seront synchronisés dans les deux sens entre Slack et GitHub, et une invitation à fusionner apparaîtra dans le canal de code une fois la demande d’intégration approuvée et les tests réussis. Un onglet Agents & Tools amélioré figure également parmi les nouveautés bientôt disponibles. Il offrira une vue d’ensemble des conversations avec les agents et des canaux de code, avec leur état, les membres des canaux et le contexte récent, ainsi que la possibilité de parcourir les canaux de code publics.

Slack a présenté trois façons de commencer : consulter la documentation et ajouter l’API au manifeste d’un agent, soumettre un agent à la place de marché Slack ou essayer les agents Slack Code disponibles dans la place de marché, notamment Claude, Devin, GitHub Copilot et Vercel.