Slack Code : quand le terminal déménage dans la conversation
Il y a des annonces qui ajoutent une case à cocher dans un comparatif, et il y a celles qui déplacent le meuble. Celle du 20 août appartient à la seconde catégorie. Slack a présenté Slack Code, une manière de faire travailler les agents de code non plus dans un onglet privé, mais au milieu de la conversation, là où tout le monde regarde.
L’idée tient en une phrase : vous mentionnez un agent dans un canal, il crée son propre espace de travail, il code, il montre ce qu’il fait, l’équipe corrige la trajectoire, et l’espace s’archive une fois le boulot terminé. Ce n’est pas une révolution technique. C’est un déplacement de scène, et ce genre de déplacement a souvent plus de conséquences qu’une nouvelle fonctionnalité.
Le problème que Slack dit vouloir régler
Depuis deux ans, travailler avec un agent de code ressemble à une activité solitaire. Une personne, un terminal ou un onglet, une conversation privée avec une IA, et un résultat qui apparaît une fois terminé. Slack décrit exactement ce scénario dans son billet d’annonce : quelqu’un s’isole, construit, et le reste de l’équipe découvre le travail après coup, sans avoir pu signaler une hypothèse fausse ou apporter le contexte qui manquait.
L’entreprise raconte avoir buté sur ce mur en interne. Ses propres développeurs se sont mis à utiliser massivement des agents, et les fils de discussion classiques n’ont pas tenu la charge : trop étroits pour une exécution longue et bavarde, trop bruyants pour le reste du canal. La solution alternative, laisser chacun repartir dans son navigateur, revenait à perdre ce qui fait l’intérêt de l’outil.
Ce qu’est concrètement un canal de code
Un canal de code se crée à partir d’une conversation existante, en emportant son contexte. C’est l’agent qui l’ouvre, pas l’utilisateur, et c’est lui qui le referme. Dans cet espace, il ne publie pas seulement du texte mais des objets manipulables, ce que la documentation développeur appelle des artefacts :
- Des diffs de code, pour voir précisément ce qui change
- Des vues Block Kit, pour des interfaces interactives structurées
- Des aperçus HTML, pour tester un prototype sans quitter Slack
- Des canvas, pour la documentation et les contenus plus longs

Le cycle de vie complet appartient à l’agent : il ouvre le canal quand la tâche le justifie, publie ses avancées, puis clôt la session. Le canal s’archive automatiquement mais reste consultable, ce qui produit au passage une trace d’audit intégrale de la manière dont un correctif a été conçu. Pour qui a déjà cherché à comprendre six mois plus tard pourquoi une ligne existe, l’argument n’est pas mince.
Côté partenaires, Slack est parti avec Anthropic, Cognition, GitHub, OpenAI et Vercel. Claude, Devin, GitHub Copilot et l’agent Vercel sont opérationnels dès le lancement, ChatGPT est annoncé pour plus tard. La fonctionnalité est disponible sur tous les forfaits, y compris gratuits, avec une nuance importante : il faut disposer par ailleurs de son propre accès à l’agent concerné. Slack ne facture pas le canal, mais ne vous offre pas l’IA qui va dedans.
Un exemple, pour voir ce que ça change vraiment
Prenons une situation banale, celle d’un site éditorial avec une offre d’abonnement. Utopiaz par exemple. Un lecteur signale que le bouton de souscription se superpose au menu sur son téléphone. La personne qui gère les réseaux sociaux voit le message et le relaie dans le canal de l’équipe.
Dans le monde d’avant, cette remarque suivait un chemin connu : elle était notée quelque part, jugée trop mineure pour mobiliser un développeur, et elle finissait au fond d’un backlog. Six semaines plus tard, elle y était encore.
Avec un canal de code, la séquence devient la suivante. La personne mentionne l’agent dans le fil, en décrivant le problème en français courant, sans jargon. Un canal se crée, emportant la capture d’écran et le contexte de la discussion. L’agent identifie le fichier de styles concerné, propose une correction du point de rupture responsive, et publie un diff de quelques lignes. Un aperçu HTML apparaît dans la foulée, permettant à chacun de vérifier le rendu sur une largeur d’écran mobile.
C’est là que la partie collective prend son sens. Le développeur de l’équipe jette un œil au diff et remarque que le correctif traite le symptôme plutôt que la cause, parce que le vrai souci vient d’une hauteur fixe héritée d’un composant plus ancien. Il le dit dans le canal. L’agent reprend, corrige à la racine, republie. La personne qui a signalé le bug valide visuellement, quelqu’un approuve, et la modification part sous forme de pull request classique dans le dépôt, où les processus de relecture habituels s’appliquent toujours.
Durée totale : une demi-heure. Nombre de tickets créés : zéro. Nombre de personnes ayant dû ouvrir un éditeur de code : zéro également, alors que le résultat a bel et bien été relu par quelqu’un qui sait lire du code. Slack affirme que plus de 70 % des canaux de code ouverts chez eux naissent et se referment dans la même journée, de l’idée à la fusion. Le chiffre vient de l’entreprise elle-même et mérite d’être pris pour ce qu’il est, mais il décrit assez bien ce type de scénario.
Slack a mis en ligne une démonstration vidéo qui suit exactement ce genre d’enchaînement, du signalement initial à la validation finale :
La question qui fâche : et la qualité dans tout ça ?
L’objection est évidente. Si n’importe qui peut convoquer un agent de code, l’entreprise ne va-t-elle pas se noyer sous une production plausible en apparence et bancale au fond, ce que le secteur appelle désormais le slop ?
La réponse de Slack est contre-intuitive : c’est justement la visibilité qui protège. Katie Steigman, vice-présidente produit, a défendu devant la presse l’idée que le regard des autres agit comme un garde-fou, puisque chacun peut commenter et réorienter le travail en cours. Elle oppose cela à la situation actuelle, où personne ne voit ce qui se passe dans un terminal. Product manager et non développeuse, elle décrit sa propre pratique comme un modèle : elle mentionne systématiquement un ingénieur de son équipe sur ses pull requests, et raconte que celui-ci lui demande presque toujours de resserrer quelque chose, l’agent produisant alors une version supplémentaire qui a été touchée par un regard technique.
L’argument se tient. Il repose toutefois sur une hypothèse fragile : que quelqu’un regarde vraiment. Rob Seaman, directeur général par intérim de Slack, a lui-même esquissé la trajectoire attendue, en prédisant que les équipes examineront tout au début, puis de moins en moins à mesure que la confiance s’installe. C’est une description assez juste de la nature humaine, et c’est précisément ce qui devrait inquiéter. Le garde-fou n’est solide que tant que l’attention tient.
Les données du marché invitent d’ailleurs à la prudence. Gartner prévoyait l’an dernier que plus de 40 % des projets d’IA agentique seraient abandonnés d’ici fin 2027, en raison de coûts qui dérapent et de bénéfices mal identifiés. L’enquête State of AI de McKinsey montre de son côté que si une large majorité d’organisations expérimentent des agents, seule une minorité constate un effet mesurable sur ses résultats. L’écart entre l’enthousiasme et la valeur reste la caractéristique dominante du secteur.
Le modèle de permissions, l’argument le plus solide
C’est sans doute la partie la plus rassurante du dossier, et la plus utile pour qui devra défendre l’outil devant un responsable informatique. Interrogé sur le risque de fuite d’accès entre équipes, Rob Seaman a été catégorique : tout se fait au nom de l’utilisateur, avec ses propres droits, dans Slack comme dans les systèmes connectés. Pas de permissions divines, pas d’identité de service créée pour l’occasion.
Katie Steigman précise que lorsqu’un agent ouvre un canal de code, il n’en récupère que le contexte de la conversation à l’origine de la demande. Côté exécution, Cognition indique faire tourner Devin dans des bacs à sable isolés avec un accès minimal, y compris un mode sans aucune connexion internet. Slack ajoute que les échanges avec un agent restent soumis aux mêmes dispositifs que le reste de l’outil, chiffrement des clés, prévention des fuites de données et API de conformité comprises.
Ce choix d’un agent considéré comme prolongement de l’utilisateur plutôt que comme entité autonome est un vrai avantage face aux plateformes d’agents indépendantes, qui obligent les équipes informatiques à provisionner de nouvelles identités et à gérer un patchwork de droits. Et comme les agents produisent des pull requests standard, les garde-fous existants du dépôt continuent de s’appliquer. Les administrateurs peuvent d’ailleurs interdire à un profil non technique de livrer du code sans relecture par un ingénieur.
Un pari qui dépasse le produit
Difficile de lire cette annonce sans la replacer dans la situation de Salesforce. L’action a nettement décroché sur un an, le marché doutant que l’IA préserve la demande pour les logiciels d’entreprise traditionnels, et le départ de la directrice générale de Slack vers OpenAI en décembre a laissé la maison en intérim. Faire de Slack la porte d’entrée du travail assisté par IA est devenu une nécessité stratégique.
On notera au passage un revirement savoureux. En 2025, Salesforce avait choisi de bloquer l’accès des IA concurrentes aux données Slack, dans un réflexe défensif. L’annonce d’aujourd’hui fait l’inverse : elle courtise ces mêmes entreprises comme partenaires et promet d’ouvrir les API des canaux de code à l’ensemble des développeurs. Le calcul a changé. Protéger la donnée comptait hier, devenir le lieu où les agents travaillent compte davantage aujourd’hui.
Ce que j’en retiens
Personne chez Slack ne prétend enterrer le terminal, et c’est plutôt bon signe. Rob Seaman décrit une division du travail : l’essentiel du volume dans ces environnements collectifs, et le travail de fond, celui qui demande une immersion longue sur une architecture, en solitaire. Cela correspond assez bien à l’expérience réelle.
Ce qui me paraît le plus intéressant n’est pas la prouesse technique, franchement modeste, mais le déplacement du geste. Faire passer le développement d’une activité privée à une activité observable change la nature de ce qui se discute. On ne débat plus d’un résultat livré, on intervient pendant. Reste à savoir si les équipes garderont l’énergie de regarder, ou si les canaux de code deviendront ces fils que tout le monde a rejoints et que plus personne ne lit. La réponse ne dépendra pas de Slack.
Sources : billet d’annonce Slack du 20 août 2026, page produit et changelog développeur Slack, et compte rendu de conférence de presse publié par VentureBeat. Visuels : Slack.
Partager cet article