Ce qui est confirmé
GitHub a publié le 28 août 2026 son récapitulatif hebdomadaire des évolutions de Copilot. La mise à jour concerne les échanges d’équipe dans Slack et Microsoft Teams, l’application Copilot, la CLI et plusieurs environnements de développement. Le point central est clair : GitHub cherche à rendre les sessions d’agents plus continues, plus configurables et davantage pilotables par les équipes.
Le détail des annonces est disponible dans le changelog officiel de GitHub. Ici, je distingue ce qui est confirmé, ce que cela peut changer dans un workflow, et ce qui reste à vérifier avant de revoir tes habitudes de travail.
Ce que GitHub confirme cette semaine
Fait. GitHub indique que Copilot peut désormais transformer des conversations d’équipe dans Slack et Microsoft Teams en sessions d’agents partagées. Dans ces espaces, la mention @GitHub peut servir à investiguer un problème, planifier un travail ou apporter des modifications suivies par l’équipe, selon le changelog GitHub.
Cette annonce ne signifie pas qu’un agent doit agir seul. Le texte officiel insiste au contraire sur la capacité de l’équipe à suivre et orienter le travail. C’est une nuance importante. Un outil connecté à une conversation peut accélérer la collecte d’informations ou la préparation d’un plan, sans devenir automatiquement un processus fiable de validation ou de déploiement.
Fait. Dans l’application Copilot, l’onglet Customize est annoncé comme généralement disponible. GitHub y rassemble les serveurs MCP, les plugins, les skills et les canvases. L’entreprise précise aussi que des issues et pull requests Azure DevOps peuvent être transformées en sessions Copilot depuis cet espace de personnalisation.
Pour suivre le contexte plus large du sujet, tu peux consulter mes actualités consacrées aux agents IA. Le point intéressant n’est pas seulement la liste des composants. C’est la tentative de concentrer dans une même interface les briques qui définissent le comportement d’un assistant de développement.
Fait. GitHub annonce également un support expérimental de Windows Subsystem for Linux, ou WSL, dans l’application Copilot. L’application peut aussi afficher des onglets côte à côte, déplacer un onglet et envoyer un aperçu de navigateur vers un navigateur externe depuis son menu contextuel.
Le qualificatif « expérimental » mérite d’être conservé. Il confirme qu’une prise en charge est annoncée, mais il ne permet pas d’en déduire la stabilité pour chaque machine, chaque distribution Linux ou chaque politique informatique d’entreprise. Avant de l’intégrer à un flux de production, il faut donc le tester dans ton environnement réel.
Copilot CLI : plus de paramètres et une reprise de session
Fait. Pour Copilot CLI, GitHub annonce deux réglages de démarrage : defaultMode et defaultPermissionMode. Ils permettent de définir des modes d’exécution et d’autorisation préférés pour les nouvelles sessions. GitHub mentionne aussi de nouvelles expériences dans /plugin, /mcp et /skills afin de gérer ces éléments plus facilement.
Le sujet des permissions devient concret dès qu’un agent peut lire des fichiers, lancer des commandes ou modifier un dépôt. Une configuration par défaut peut faire gagner du temps. Elle peut aussi rendre une action trop facile à déclencher si elle est choisie sans tenir compte du contexte.
Analyse. Pour un indépendant ou une petite équipe, je vois surtout une occasion de formaliser ce qui était souvent implicite. Tu peux distinguer une session dédiée à l’exploration, une session de rédaction de code, puis une session de revue. Le bénéfice ne vient pas du fait d’automatiser davantage. Il vient du fait de décider à l’avance ce que l’agent a le droit de faire dans chaque cadre.
Ce principe rejoint ce que j’explique dans mon article sur les environnements isolés et Copilot CLI. La vitesse n’a de valeur que si le périmètre de l’action reste compréhensible et contrôlable.
Fait. GitHub annonce que Copilot CLI peut restaurer des sessions qui ne se sont pas terminées proprement, y compris lorsqu’elles ont été interrompues pendant un tour. GitHub indique aussi que la CLI repose désormais sur un runtime Rust natif, tandis que son interface de terminal reste construite en TypeScript.
Le changelog emploie l’expression « significantly faster performance ». C’est une indication de l’éditeur, pas une mesure publiée pour ton projet. GitHub ne fournit pas dans cette annonce de protocole de benchmark, de durée de tâche, de comparaison matérielle ou de résultat chiffré par cas d’usage.
Ce qui reste inconnu. Avec la seule annonce disponible, on ne peut pas affirmer le gain de temps observé sur un dépôt particulier. On ne peut pas non plus conclure que la reprise de session reconstruit parfaitement le contexte d’une tâche interrompue. Ce sont deux comportements à vérifier avec une tâche représentative, un historique de changements et une revue humaine.
Pourquoi c’est important
IDE : continuité entre outils et contrôles d’entreprise
Fait. Pour JetBrains, GitHub annonce des contrôles d’entreprise cohérents concernant les plugins, les serveurs MCP, la télémétrie et les modes d’autorisation des agents. Cette information concerne les organisations qui utilisent ces contrôles, pas une promesse générale sur chaque installation individuelle.
Si tu travailles déjà avec cet environnement, mon point précédent sur Copilot, JetBrains, mémoire et Ollama donne un contexte utile. Il faut cependant séparer les annonces. Le changelog du 28 août confirme des contrôles d’entreprise pour JetBrains. Il ne détaille pas leur paramétrage précis, ni les règles internes de chaque organisation.
Fait. GitHub indique que VS Code 1.135 permet de continuer des sessions récentes d’agents Copilot ou Claude provenant d’autres applications. La mise à jour comprend aussi une possibilité d’obtenir un second avis d’un modèle complémentaire afin de faire ressortir des détails ou cas limites potentiellement oubliés.
Analyse. La continuité de session peut éviter de reformuler sans cesse un problème technique. Pourtant, elle ne dispense pas d’une remise à plat. Un contexte ancien peut contenir une hypothèse erronée, un fichier déjà modifié ou une intention devenue obsolète. À mon avis, la bonne pratique reste de relire l’objectif et le diff avant toute modification persistante.
Fait. GitHub mentionne également une interface Agents sur un seul panneau dans VS Code, des contrôles de session simplifiés, des détails de session plus accessibles, ainsi que le détail de l’usage du chat par modèle et par tour. Ces éléments relèvent de l’ergonomie et de la visibilité du travail effectué dans l’outil.
La visibilité est un sujet souvent moins spectaculaire que les modèles. Pourtant, elle compte pour une équipe. Savoir quel modèle a été sollicité ou pouvoir retrouver le déroulé d’une session aide à discuter du résultat. Cela ne prouve pas que le résultat est correct, mais cela donne davantage de matière pour le contrôler.
Visual Studio : modèles, consommation et revue avant pull request
Fait. Dans Visual Studio, GitHub annonce la possibilité d’épingler des modèles favoris, de masquer des modèles inutilisés, de comparer leurs capacités et leurs coûts, puis d’ajuster l’effort de raisonnement pour chaque tâche. GitHub mentionne aussi le partage d’agents personnalisés dans une organisation.
Fait. L’annonce indique que les utilisateurs peuvent consulter la consommation de leur plan Copilot et gérer l’usage des modèles premium avant d’atteindre des limites. GitHub annonce enfin une revue des changements non commités ou de commits individuels avec l’agent Git avant l’ouverture d’une pull request.
Analyse. Pour un entrepreneur qui facture son temps ou pilote un SaaS, cette partie est probablement la plus opérationnelle. Un modèle n’est pas seulement une qualité de réponse. Il implique un coût potentiel, un délai et une manière de travailler. Mettre les informations de consommation près de l’usage peut rendre les arbitrages plus visibles.
Je te conseille de relier cette observation à une question simple : quelle tâche veux-tu accélérer, et comment vas-tu vérifier le résultat ? Une revue de code assistée peut signaler un angle mort. Elle ne remplace pas la responsabilité de la personne qui valide la pull request. Pour approfondir la logique de revue, tu peux lire mon article sur la revue de code Copilot pour les grandes pull requests.
Ce que cela change pour toi
Concrètement, les nouveautés Copilot d’août 2026 dessinent trois évolutions. La première est le passage d’un assistant individuel à des sessions davantage partagées dans les outils de conversation. La deuxième est la centralisation de la personnalisation avec MCP, plugins, skills et canvases. La troisième est une recherche de continuité entre l’application, la CLI et les IDE.
Aucune de ces évolutions ne doit te pousser à déléguer sans cadre. Si tu travailles seul, commence par une tâche limitée : analyser un bug, préparer un plan de correction ou relire un diff. Si tu travailles en équipe, définis qui peut lancer une session, quelles permissions sont admises et qui décide de fusionner une modification.
Mon conseil pratique est de documenter une règle courte avant de tester. Par exemple : l’agent peut proposer un plan et modifier une branche de travail, mais une personne relit le diff et exécute les contrôles du projet avant validation. Cette règle n’est pas annoncée par GitHub. C’est une méthode de prudence que je recommande pour éviter de confondre assistance et autonomie complète.
Tu peux aussi comparer cette actualité avec les autres analyses IA du blog et retrouver les publications récentes dans la rubrique actualités. Mon objectif est de garder une lecture utile pour les créateurs et entrepreneurs : partir d’une annonce vérifiable, puis la traduire en décision de travail.
Ce que cela change
Pour les équipes qui construisent un produit ou un site, le sujet rejoint naturellement les méthodes de mon agence AskOptimize : automatiser un processus n’a de sens que si les objectifs, les accès et les critères de validation sont explicites.
Mon avis
À mon avis, la nouveauté la plus utile n’est pas forcément la plus visible. Les réglages de permissions, la reprise de session et la visibilité de l’usage peuvent améliorer un vrai workflow si tu les relies à une méthode de revue. Je reste prudent sur les promesses de rapidité sans mesure publiée pour un cas concret. Je préfère tester un flux sur une tâche répétable, puis décider avec des résultats observables.
FAQ
Quelles sont les principales nouveautés GitHub Copilot annoncées le 28 août 2026 ?
GitHub annonce des sessions d’agents partagées dans Slack et Microsoft Teams, l’onglet Customize généralement disponible dans l’application Copilot, des évolutions de Copilot CLI et des nouveautés dans JetBrains, VS Code et Visual Studio. Le détail est présenté dans le changelog officiel.
Copilot peut-il travailler depuis Slack ou Microsoft Teams ?
Selon GitHub, la mention @GitHub dans Slack et Microsoft Teams peut lancer des sessions d’agents partagées pour investiguer, planifier ou effectuer des changements suivis par l’équipe. L’annonce ne remplace pas une validation humaine des modifications.
Que permet l’onglet Customize de l’application Copilot ?
GitHub indique que Customize rassemble les serveurs MCP, les plugins, les skills et les canvases. L’entreprise précise aussi que cet espace peut transformer des issues et pull requests Azure DevOps en sessions Copilot.
Copilot CLI est-il plus rapide avec le runtime Rust ?
GitHub affirme que la CLI bénéficie de performances sensiblement plus rapides grâce à un runtime Rust natif. L’annonce ne fournit pas de benchmark chiffré ni de résultat garanti pour ton dépôt. Il faut donc mesurer le comportement sur tes tâches.
Faut-il laisser Copilot modifier directement un projet ?
C’est un choix de méthode, pas une obligation annoncée par GitHub. Selon moi, tu peux autoriser des modifications dans un périmètre limité, à condition de relire le diff, d’exécuter les vérifications du projet et de conserver une validation humaine avant toute mise en production.
Information et avertissement
Cet article présente une annonce produit à partir de la source officielle citée. Il ne constitue ni une garantie de disponibilité dans ton environnement, ni un conseil de sécurité, ni une recommandation d’achat. Vérifie les permissions, les politiques de ton organisation et les résultats obtenus avant d’utiliser un agent IA sur un projet, des données ou une infrastructure sensibles.
Sources et méthode
Les informations ont été vérifiées à partir des sources ci-dessous.
Les faits confirmés sont distingués des analyses et des limites encore ouvertes.
