Du message d’équipe à la tâche technique

Une demande de développement naît souvent dans un canal : un collègue signale un bug, joint une capture, partage un fichier ou transmet un message contenant une décision. Jusqu’ici, faire passer ces éléments vers un outil de suivi demandait souvent de reconstituer le contexte à la main. Selon le changelog officiel de GitHub, Copilot peut désormais prendre en compte davantage d’éléments déjà présents dans Slack ou Teams lorsqu’on lui demande de travailler.

Dans Slack, GitHub mentionne les fichiers compatibles, les pièces jointes et les liens vers des messages. Dans Microsoft Teams, l’annonce cite les images intégrées, les messages transférés ainsi que l’historique des canaux et des fils de discussion. La formulation compte : « fichiers compatibles » ne veut pas dire tous les formats de fichiers, et le changelog ne publie pas une liste exhaustive des types acceptés. De même, la capacité à utiliser l’historique d’un fil n’autorise pas à présumer que l’agent voit toutes les conversations de l’organisation. Ses accès restent conditionnés par l’intégration, le compte connecté et les réglages de l’espace de travail. Annonce GitHub.

Moins de tickets doublons, plus de traçabilité

GitHub indique que Copilot recherche des issues similaires avant d’en créer une nouvelle. L’agent ajoute aussi des liens directs vers le travail généré et conserve un lien avec la conversation d’origine. Ce détail est plus important qu’un simple confort d’interface. Si une issue ou une proposition de changement est créée depuis une discussion, l’équipe doit pouvoir retrouver le problème initial, les fichiers partagés et la décision qui l’a motivée. La traçabilité facilite ensuite la revue humaine : on peut vérifier si le résultat répond bien à la demande de départ. Changelog du 25 septembre.

Cette recherche d’issues similaires ne promet pas la disparition des doublons. GitHub ne publie ni taux de détection indépendant ni garantie de correspondance parfaite dans sa courte annonce. Il faut donc continuer à vérifier la qualité du ticket créé, son dépôt cible et la pertinence des références proposées. Un lien vers la conversation d’origine rend le travail plus facile à auditer ; il ne remplace pas un diagnostic technique.

Un choix de modèle et des réglages plus fins

Le changement le plus visible pour les utilisateurs avancés est la possibilité de changer de modèle pour le message suivant, puis de conserver ce choix pendant la conversation. Cela permet, selon les modèles disponibles dans l’organisation, d’adapter l’assistance à une tâche donnée. GitHub n’indique pas dans ce changelog que tous les modèles sont accessibles à tous les clients, ni que le changement contourne les politiques définies par les administrateurs. Dans Slack, l’annonce ajoute le réglage de propriétaires et de dépôts par défaut, afin de mieux orienter les demandes récurrentes. Annonce GitHub.

GitHub mentionne aussi des corrections de fiabilité : meilleure reprise de plans d’implémentation, messages plus clairs lorsqu’une tâche s’interrompt, reconnexions plus prévisibles et réduction des réponses en doublon dans Teams. Dans Slack, l’entreprise dit avoir corrigé des problèmes de sélection de dépôt et empêché des sessions dépassées de continuer à agir dans un ancien dépôt après un changement. Ces points intéressent particulièrement les équipes qui lancent du travail depuis plusieurs canaux et dépôts. Ce sont des améliorations déclarées par l’éditeur, sans mesure publique permettant ici de quantifier le gain. Changelog GitHub.

Qui peut l’utiliser, et à quel coût ?

L’aperçu public est destiné aux organisations abonnées à GitHub Copilot Business ou GitHub Copilot Enterprise. L’usage est comptabilisé dans les droits Copilot existants et peut être géré avec les budgets de l’agent cloud. Le communiqué ne donne pas de prix supplémentaire propre à Slack ou Teams, ni de tarification détaillée par action. Il signale que certaines capacités sont déployées progressivement : même une organisation éligible peut ne pas voir immédiatement toutes les nouveautés. Aucun calendrier géographique détaillé n’est fourni. Section disponibilité du changelog.

L’activation demande également des réglages d’administration. Pour Slack, GitHub demande que la politique de l’agent cloud soit activée, que l’application GitHub soit installée ou mise à jour, puis que l’utilisateur lie son compte GitHub et mentionne @GitHub dans une conversation. Pour Teams, l’administrateur doit activer l’agent cloud et les cloud sandboxes ; l’utilisateur installe ou met à jour l’application GitHub pour Teams, mentionne @GitHub et suit la connexion du compte. Les instructions Slack et Teams fournissent les étapes opérationnelles. Elles comptent davantage qu’une simple annonce si l’on veut évaluer la disponibilité dans une équipe réelle.

Pourquoi ce lancement compte pour les équipes

GitHub rapproche un agent de programmation des lieux où se prennent déjà les décisions. Le gain potentiel tient moins à la création automatique d’une issue qu’à la continuité du contexte : une demande, ses pièces jointes, le travail GitHub produit et sa justification peuvent rester reliés. Mais cette continuité dépend des accès accordés, des politiques d’organisation et de la capacité de l’équipe à relire le résultat. Une capture ou un message transféré peut apporter un contexte utile ; il peut aussi être incomplet ou ambigu. La revue par un développeur reste donc essentielle avant de valider un changement de code.

La bonne question pour une organisation n’est pas seulement « Copilot est-il dans Slack ou Teams ? », mais « quels canaux, dépôts et budgets sont effectivement ouverts à l’agent, et comment vérifie-t-on ses actions ? ». Le lancement du 25 septembre améliore l’intégration ; il ne transforme pas un fil de discussion en spécification infaillible. Annonce primaire GitHub.

Sources

État des informations : 26 septembre 2026.