Slack Code transforme le développement logiciel en projet d’équipe avec l’IA

Slack veut sortir le développement assisté par IA des échanges en tête-à-tête entre un développeur et un agent. Annoncé par Salesforce le 20 août 2026, Slack Code crée un canal dédié dans lequel les humains et les agents peuvent planifier une tâche, suivre son avancement, examiner les modifications et décider de la suite.

L’idée défendue par Slack est celle d’un développement « multijoueur » : au lieu de rester dans un terminal ou une interface privée, le travail de l’agent devient visible dans l’espace où l’équipe échange déjà sur le projet.

Comment fonctionne Slack Code ?

Le parcours commence généralement par une idée, un bug, une mise à jour de site web ou une demande de nouvelle fonctionnalité dans une conversation Slack :

1. Un membre de l’équipe mentionne un agent de codage compatible.
2. L’agent ouvre un canal dédié au projet ou à la session.
3. Les participants précisent les objectifs, les contraintes et le contexte métier.
4. L’agent propose un plan et prépare les changements.
5. L’équipe examine le code produit, les différences avec la version précédente et les aperçus disponibles.
6. Les participants peuvent demander une autre approche, corriger la trajectoire ou approuver l’étape suivante.

Selon l’intégration utilisée, le canal peut donner accès à plusieurs vues : la conversation, le plan de travail de l’agent, les diffs — c’est-à-dire les lignes ajoutées, supprimées ou modifiées — et un aperçu en direct du résultat, notamment en HTML. Slack ne se contente donc pas d’afficher une transcription : il cherche à réunir le contexte de la demande et le logiciel généré au même endroit.

Quels agents sont compatibles ?

Salesforce cite notamment Claude Code et Claude Tag d’Anthropic, Devin de Cognition, GitHub Copilot, ChatGPT d’OpenAI et les agents de Vercel.

La présence d’un agent dans Slack Code ne signifie toutefois pas que toutes les intégrations offrent exactement les mêmes fonctions. Les plans détaillés, les aperçus, les différences de code ou les actions d’approbation dépendent des capacités mises à disposition par chaque éditeur.

Les chefs de produit et les designers peuvent-ils participer ?

C’est l’un des changements les plus visibles par rapport à un workflow centré sur le terminal du développeur. Un chef de produit peut décrire le problème utilisateur, ajouter des informations sur les priorités ou les règles métier, puis examiner le résultat sans devoir travailler directement dans l’environnement de développement. Un designer peut lui aussi réagir à un aperçu et demander des ajustements.

Les développeurs conservent, eux, la responsabilité de l’évaluation technique : qualité du code, compatibilité avec l’architecture existante, sécurité et risques opérationnels.

Un exemple de workflow serait le suivant : un chef de produit signale dans Slack un formulaire qui ne fonctionne plus comme prévu. L’agent analyse la demande et propose un correctif. L’ingénieur examine ensuite le diff, vérifie les effets possibles sur le reste du projet et décide si le changement peut donner lieu à une demande de fusion — une pull request — ou s’il faut recommencer une itération.

L’approbation humaine reste indispensable

Slack Code est présenté comme une couche de visibilité et de collaboration, pas comme une autorisation de déployer automatiquement du code non vérifié. Les équipes peuvent imposer une validation humaine avant les actions sensibles, notamment celles susceptibles d’atteindre la production.

Cette précaution est importante : un agent peut produire un correctif qui semble convaincant sans comprendre entièrement les exigences métier, les contraintes de sécurité ou les conséquences d’une modification sur un système en fonctionnement. Le canal partagé permet aux personnes responsables de questionner la solution, de demander des révisions et de conserver la trace de la décision avant que le travail n’avance.

Un historique conservé et les contrôles habituels de Slack

Une fois la tâche terminée, les canaux de code peuvent être archivés tout en conservant leur conversation et leur historique de travail dans les recherches Slack. L’organisation dispose ainsi d’une trace de la demande initiale, des résultats produits par l’agent et des échanges ayant conduit à la validation.

Le travail restant dans Slack, les entreprises peuvent s’appuyer sur leurs identités, leurs permissions, leurs règles de gouvernance, leurs paramètres de sécurité et leurs contrôles administratifs existants, sans mettre en place une plateforme de collaboration distincte pour chaque tâche confiée à un agent.

L’intérêt pratique est la continuité : les exigences du projet, les arbitrages, les revues et l’activité de l’agent restent rattachés à la discussion dans laquelle le besoin est apparu.

Disponibilité et partenaires au lancement

Salesforce a indiqué que Slack Code était disponible sur tous les forfaits Slack dès son lancement. Les intégrations fondatrices annoncées provenaient d’Anthropic, de GitHub, de Cognition et de Vercel ; ChatGPT figurait également parmi les agents pouvant participer à ces espaces.

La disponibilité d’une fonction donnée peut donc varier selon l’agent et sa connexion à Slack. Les entreprises devront vérifier, intégration par intégration, quelles opérations peuvent être exécutées et lesquelles nécessitent une validation supplémentaire.

La stratégie de Salesforce : coordonner plusieurs fournisseurs d’IA

À l’occasion de Dreamforce, Salesforce a présenté Slack Code comme un moyen de faire du développement logiciel une activité collective, avec des humains et des agents réunis dans le même canal.

Le positionnement est aussi stratégique : Slack se présente comme la couche de coordination capable d’accueillir des agents de fournisseurs concurrents, plutôt que comme l’interface d’un unique modèle de génération de code. Une équipe pourrait ainsi conserver son espace de travail commun tout en utilisant différents agents selon la tâche.

Salesforce a par ailleurs évoqué une ouverture plus large des API sous-jacentes. À terme, les organisations pourraient créer des agents et des canaux partagés pour des tâches qui dépassent le développement logiciel, par exemple la coordination de campagnes marketing ou l’examen de documents juridiques. Ces exemples correspondent à une orientation prévue et ne signifient pas que tous ces usages sont déjà disponibles de manière générale.

À retenir

Slack Code ne se distingue pas uniquement par la capacité d’un agent à générer du code. Sa proposition centrale consiste à rendre ce travail visible et discutable par toute l’équipe : mentionner un agent, lui attribuer un canal de projet, suivre son plan, examiner le résultat et valider — ou refuser — la prochaine étape.

Pour les organisations déjà structurées autour de Slack, cette approche pourrait faciliter la participation des équipes produit et design tout en maintenant la revue technique côté ingénierie. Son efficacité dépendra toutefois de la qualité de chaque intégration et de règles d’approbation suffisamment strictes pour les changements sensibles.