Au cœur de l’API Code se trouve un type de canal conçu spécifiquement pour les tâches confiées aux agents. À partir d’une conversation, un agent peut créer un canal de programmation, y ajouter les bonnes personnes et les bons fichiers, publier des différences de code et des aperçus, enregistrer les éléments importants, puis présenter un plan étape par étape et des mises à jour d’avancement. Une fois la tâche terminée, le canal peut être archivé. Il bénéficie des fonctionnalités déjà présentes dans l’espace de travail en matière d’accès, de conformité et de recherche. Il s’agit d’une couche d’intégration : Slack fournit les primitives nécessaires pour éviter aux agents de devoir recréer de toutes pièces les interfaces de collaboration, d’approbation ou de révision.

Pour les développeurs, l’étape principale consiste à ajouter Slack Code au manifeste de l’agent. Celui-ci définit le nom du canal, les règles de sélection des membres, les commandes et les vues. Lorsqu’un agent détermine qu’une demande nécessite un espace de travail dédié, il crée le canal, invite automatiquement les collègues et parties prenantes concernés, puis publie un plan initial et les éléments requis. Pendant l’exécution, il partage des différences de code, des résultats de tests et des points d’étape ; les collègues peuvent commenter, réorienter le travail ou l’approuver. Pour les équipes qui mettent en œuvre l’API, il est recommandé de définir clairement les étapes du cycle de vie (ouverture, mise à jour, demande d’approbation, archivage) et d’adapter la fréquence des mises à jour à la capacité d’attention des personnes afin que les canaux restent utiles.

L’un des compromis assumés de l’API Code consiste à privilégier la visibilité plutôt que la confidentialité. Les agents héritent des autorisations des canaux et des règles de conformité des messages, ce qui permet aux équipes de sécurité de disposer d’une piste d’audit claire sans avoir à créer de nouveaux systèmes d’accès. C’est essentiel pour les entreprises réglementées et celles qui doivent pouvoir retracer les raisons d’un changement. Toutefois, cette visibilité soulève aussi des questions de politique interne : quels résultats des agents devraient être publics par défaut ? Quand les brouillons temporaires devraient-ils rester privés ? Comment éviter que des éléments sensibles ne soient exposés dans un canal largement accessible ? Les équipes doivent accompagner l’API de politiques et de filtres adaptés à leur niveau de risque.

Les partenaires du lancement de Slack illustrent plusieurs cas d’usage : Copilot recourt aux canaux de programmation lorsqu’une tâche nécessite la participation de collègues ; des agents d’observabilité peuvent ouvrir des canaux pendant un incident et y joindre des journaux ; des outils de déploiement peuvent demander l’approbation d’une pull request directement dans le canal. Ces exemples montrent que l’API Code ne se limite pas aux petites modifications : elle prend en charge des flux de travail complets, du triage jusqu’à la fusion du code. Pour les fournisseurs, l’API permet aux agents des places de marché de proposer une expérience cohérente dans Slack, d’améliorer leur visibilité et de simplifier l’adoption pour les clients qui souhaitent utiliser leurs propres agents (BYOA).

Rendre public le travail des agents présente des avantages, mais peut aussi compliquer les choses. Les équipes risquent de souffrir d’une surcharge de notifications si les agents publient trop de mises à jour intermédiaires. Les équipes chargées de la gouvernance doivent empêcher l’exfiltration des données et appliquer le principe du moindre privilège. Les intégrations qui nécessitent une interface fortement personnalisée ou une gestion complexe des états peuvent toujours exiger des outils externes. Enfin, les processus d’approbation humaine doivent être soigneusement conçus afin d’éviter qu’ils ne deviennent des goulots d’étranglement ou de simples formalités. Avant d’accorder largement des autorisations aux agents, les premiers utilisateurs devraient mener des projets pilotes, ajuster les seuils de notification et établir des règles d’approbation claires.