Slack Code : les coding agents viennent d’entrer dans le channel de l’équipe

La chose la plus importante à propos d’un coding agent n’est plus sa capacité à écrire du bon code. C’est de savoir qui peut voir ce qu’il fait. Jusqu’à ce mois-ci, la réponse honnête pour la plupart des équipes était : un developer, dans un terminal privé ou browser tab, espérant se souvenir plus tard de ce que l’agent a réellement fait. Slack Code, lancé le 20 août, est la plus grande tentative à ce jour de faire de la réponse "tout le projet, par défaut."

J’ai lu l’annonce de lancement, le follow-up post de Slack et la coverage. Le model dessous est le même Claude Code, Devin ou Copilot que vous connaissez déjà. Ce qui change est la pièce dans laquelle le travail se déroule, et cela compte davantage que la majorité de la couverture ne le suggère.

Points clés - Slack Code ajoute des "code channels" : project spaces partagés où un coding agent taggé, Claude Code, Devin, GitHub Copilot, Vercel, avec ChatGPT annoncé, travaille en public, avec diffs, live previews et human approval avant shipping. - Cela fonctionne sur tous les Slack plans dès day one, même si l’access à chaque agent s’achète séparément. Les channels auto-archive une fois le travail terminé et gardent audit log. - Le vrai shift est supervisory : agent work passe d’une private session regardée par une personne à un shared artefact regardé par une équipe. Cela corrige des gaps d’attribution et review, et en crée d’autres, bystander apathy, approval theatre, channel context comme attack surface. - C’est aussi un distribution move. Slack a passé un an à construire de l’agent plumbing, MCP server, real-time search, Slackbot MCP client, et les code channels sont la surface qui le rend visible. - Traitez "une personne approuve le travail avant qu’il ne ship" comme design goal, pas comme garantie. Votre review process doit rester réel.

Ce qui s’est passé

Le 20 août, Slack a lancé Slack Code sur tous ses plans, free workspaces inclus. La mécanique, selon la launch coverage et TechRepublic :

• Vous taggez un coding agent dans n’importe quelle Slack conversation. L’agent ouvre un code channel dédié à la task, qu’il s’agisse de corriger un bug, mettre à jour une page ou construire une feature.

• Tout le monde dans le channel voit la même conversation de départ, review les code diffs proposés, vérifie les live HTML previews, laisse du feedback que l’agent intègre et approuve le résultat final. Rien ne ship sans human sign-off.

• Quand le travail est terminé, le channel s’archive automatiquement et conserve audit log.

• Les launch partners sont Claude d’Anthropic, Devin de Cognition, GitHub Copilot et Vercel, avec ChatGPT d’OpenAI annoncé comme prochaine intégration. Slack prévoit d’ouvrir les code channel APIs à la developer community afin que tout custom agent puisse participer.

Qui arrive dans le channel est configurable. Katie Steigman, VP of Product de Slack, a déclaré à Reworked : "You could have the agent just bring in the user who tagged the agent to make the code channel or you could configure the agent to make inferences on its own as to who should be in the channel based on the context it has." Rob Seaman, EVP et general manager de Slack, a résumé l’intention : "AI only creates value when it's part of how a team actually works."

Slack Code, lancé le 20 août 2026 sur tous les Slack plans, place des partner coding agents, Claude, Devin, Copilot, Vercel, ChatGPT annoncé, dans des "code channels" partagés où toute l’équipe voit conversation, diffs et live previews de l’agent, approuve le travail avant shipping et récupère un audit log lorsque le channel auto-archive, selon l’annonce Slack.

La supervision sort de la session privée

Voici ce que cache la feature list. La plupart de l’agent supervision aujourd’hui est une fiction maintenue par une personne fatiguée. L’agent tourne dans l’IDE de quelqu’un ou une cloud sandbox, le diff arrive en pull request, et le "review" est ce que ce developer avait l’énergie de faire à 17h. Le reasoning, les dead ends, les trois tentatives avant celle qui fonctionne : tout s’évapore. J’ai review assez d’agent output pour savoir que le diff est la partie la moins informative du process.

La vraie proposition de Slack Code est de faire du process lui-même l’artefact. Le channel conserve conversation de départ, intermediate steps, feedback pris en compte et approvals, puis archive le tout comme searchable record. C’est un supervision model vraiment différent et plus proche de la manière dont les bonnes équipes review des junior engineers que de leur façon actuelle de review les agents : regarder le travail, pas seulement output.

Cela change aussi qui supervise. Le pitch dit explicitement que PMs, designers et teammates non techniques peuvent suivre. Je suis prudemment pour, avec une réserve : une salle pleine d’observateurs n’est pas un reviewer. La diff literacy ne s’acquiert pas par osmose, et "l’équipe peut le voir" peut discrètement devenir "personne ne l’a vérifié." Les governance questions que cela soulève, qui est accountable quand dix personnes ont regardé et personne n’a owned l’approval, sont exactement celles que je traite dans le framework agent governance, et Slack Code ne les résout pas pour vous. Il les rend visibles, ce qui est la première étape honnête.

Slack Code déplace agent supervision d’une private session vers un shared, archived channel record : conversation, intermediate steps, feedback et approvals persistent comme searchable artefact, selon le product post de Slack. La question d’accountability, qui owns l’approval dans une salle d’observateurs, reste à résoudre par le customer.

Shared context coupe dans les deux sens

Le second grand claim concerne context. L’argument de Slack est que le context d’une task vit déjà dans les channels, bug report, spec discussion, customer complaint, donc l’agent devrait travailler là où se trouve le context plutôt que de le copy-paste dans un private prompt. C’est juste, et cela s’appuie sur le plumbing que Slack ship depuis un an : son MCP server et real-time search API sont devenus generally available en février, donnant aux agents governed access aux workspace messages et files, et le Slackbot MCP client a suivi en juin. J’ai expliqué pourquoi MCP access aux team tools est la moitié utile d’agent context dans le roundup MCP servers; le channel model mène cette idée à son terme.

Mais shared context signifie aussi shared exposure. Un agent qui lit un channel lit tout ce qu’il contient, y compris le message où quelqu’un a collé un credential "juste une minute" et l’external content transféré depuis un customer. Chaque security researcher que je connais dit la même chose : du content qu’un agent peut lire est du content qui peut l’instruire. Un shared channel est une prompt-injection surface plus grande qu’une private session, point final. Avant de pointer un agent avec write access vers un busy channel, soyez délibéré sur les channels qu’il lit et les tools qu’il peut toucher. C’est de l’architecture work, pas du settings work, même trade-off que dans agentic architecture : capability et blast radius grandissent ensemble.

L’avantage context de Slack Code, l’agent travaille là où le task context existe déjà, repose sur MCP-based workspace access que Slack a rendu generally available en février 2026, selon Unite.AI. Le même shared context élargit la prompt-injection et credential-exposure surface, un trade-off absent des launch materials.

Attribution et review, les gains sans glamour

Les parties les moins flashy de ce launch sont celles que j’achèterais. D’abord attribution : dans un code channel, chaque agent action est sous l’identity de l’agent, dans un workspace qui sait déjà qui est chacun, avec audit log qui survit au project. Cela semble basic. Ça l’est. C’est aussi plus d’attribution infrastructure que ce que possèdent la plupart des équipes aujourd’hui pour agent work, où "l’agent l’a fait" et "je l’ai fait" se mélangent dans la même git history. Les regulated industries demandent exactement cette chose ennuyeuse depuis un an.

Ensuite review. Diffs et live previews dans le channel, feedback incorporé par l’agent et hard approval gate avant shipping. Notez ce qui manque : les materials de Slack décrivent une personne approuvant le travail, mais rien de ce que j’ai vu ne spécifie qui doit être cette personne, ce qui lui est montré ou ce qui se passe lorsque le reviewer configuré est en vacances. Approval comme checkbox produit de l’approval theatre : un green button que tout le monde apprend à cliquer. Les équipes qui en tireront de la valeur connecteront l’approval à un vrai code owner avec vrai diff review, et garderont le channel output comme evidence plutôt que comme review.

Le competitive context compte aussi. Microsoft a mis un Copilot coding agent dans les Teams threads en septembre 2025, et Block a ship son open-source Buzz en juillet, comme le note Reworked. La chat window devient une contested surface pour agent work, et l’avantage de Slack est sans glamour : l’équipe est déjà là. Distribution bat cleverness dans collaboration software, à chaque fois.

Slack Code donne à chaque agent sa propre identity dans les channels et conserve un audit log par archived project, selon TechRepublic, mais son approval gate, "a person approves the work before it ships", ne spécifie ni reviewer identity ni review standards. Le Teams Copilot agent de Microsoft, septembre 2025, et Buzz open source de Block, juillet 2026, sont les comparables directs, selon Reworked.

Que faire maintenant

Si votre équipe utilise Slack et des coding agents, trois étapes.

1. Cette semaine : choisissez une task low-stakes et bien spécifiée, copy change ou petit bug avec reproduction claire, et exécutez-la dans un code channel avec deux ou trois personnes qui regardent. Vous ne testez pas l’agent ; vous testez le review behaviour de l’équipe. Regardez si quelqu’un lit réellement le diff.

2. Avant que quoi que ce soit de réel ne ship : décidez par écrit qui est approver de l’agent work dans chaque repo et ce qu’il doit vérifier. Si la réponse est "quiconque est dans le channel", vous n’avez pas de review process, vous avez un button.

3. Avant broad rollout : scopez les channels que l’agent peut lire et les credentials détenus par son environment. Channel history est context, et context est attack surface. Commencez étroit et élargissez sur evidence.

FAQ

Qu’est-ce que Slack Code ?

Une feature Slack lancée le 20 août 2026 qui permet de tagger des partner coding agents, Claude Code, Devin, GitHub Copilot, Vercel, avec ChatGPT annoncé, dans une conversation. L’agent ouvre un "code channel" dédié à la task, où l’équipe regarde le travail, review diffs et previews et approuve le résultat avant shipping. Le channel s’archive automatiquement à la fin.

Faut-il un Slack plan payant ?

Non. Slack Code est disponible sur tous les plans, free workspaces inclus. Mais l’access à chaque coding agent s’achète séparément auprès de son vendor, donc le coût pratique dépend des agents que vous payez déjà.

Slack Code remplace-t-il code review ?

Non, et le traiter ainsi est le principal risque. Il déplace review dans un shared archived channel et ajoute approval gate, mais la qualité du review dépend toujours d’un named human lisant le diff. Un process visible sans owner est pire qu’un process privé avec reviewer consciencieux, parce qu’il semble supervised.

Est-il sûr de laisser un agent lire tout un channel ?

Cela dépend du contenu. Tout ce que l’agent peut lire peut l’influencer, y compris pasted credentials et forwarded external content. Scopez read access étroitement, gardez les agent credentials least-privilege et traitez channel content comme untrusted input, car du point de vue de l’agent c’est exactement ce que c’est.

En bref

Slack Code ne fera pas écrire de meilleur code aux agents. Ce n’est pas son rôle. Il rend agent work visible, attributable et reviewable by default, à l’endroit où l’équipe vit déjà, et ce sont trois choses qui manquent discrètement dans la plupart des agent deployments. Le piège est que visibility n’est pas supervision. Le channel vous donne record et gate ; savoir si quelqu’un regarde vraiment reste votre problème. Regardez comment les équipes configurent l’approver, pas l’agent. C’est là que cela fonctionne ou devient theatre.

Si vous cherchez comment intégrer des agents aux team workflows sans perdre le contrôle du review, c’est une conversation que j’ai régulièrement avec mes clients. Contactez-moi.

Sources

• Salesforce, "Introducing Slack Code: Agentic Coding for Teams": https://www.salesforce.com/introducing-slack-code/ (publié 2026-08-19, consulté 2026-08-29)

• Slack, "Slack Code: Where Your Team and Agents Build Together": https://slack.com/blog/news/slack-code-channels-for-agents (publié 2026-08-28, consulté 2026-08-29)

• Unite.AI, "Slack Code Puts AI Coding Agents in Dedicated Project Channels": https://www.unite.ai/slack-code-puts-ai-coding-agents-in-dedicated-project-channels/ (publié 2026-08-20, consulté 2026-08-29)

• TechRepublic, "Slack Code: AI Coding Agents Get Shared Channels for Review and Oversight": https://www.techrepublic.com/article/news-slack-code-ai-coding-agents/ (publié 2026-08-21, consulté 2026-08-29)

• Reworked, "Slack Code Puts AI Coding Agents in Shared Channels": https://www.reworked.co/collaboration-productivity/slack-code-brings-collaborative-ai-coding-into-channels/ (publié 2026-08-20, consulté 2026-08-29)