Ce qui est confirmé
GitHub a publié le 28 août 2026 une mise à jour de GitHub Copilot dans Visual Studio 2026. Elle porte sur le choix des modèles, le niveau d'effort de raisonnement, les agents personnalisés d'organisation, le suivi d'usage et la revue de code par l'agent Git. Pour les développeurs, indépendants et équipes qui travaillent déjà dans cet environnement, le sujet n'est pas seulement l'ajout de commandes : il est de savoir quelles décisions peuvent désormais être réglées, partagées et revues dans l'éditeur. Selon le changelog GitHub, ces nouveautés concernent les plans Copilot Free, Student, Pro, Pro+, Max, Business et Enterprise.
Ce qui change dans GitHub Copilot pour Visual Studio
Fait confirmé. Le changelog de GitHub annonce plusieurs évolutions dans Copilot pour Visual Studio 2026. La plus structurante pour une organisation est la publication d'agents personnalisés au niveau de l'organisation ou de l'entreprise. Les propriétaires d'organisation et d'entreprise peuvent les publier afin qu'ils soient utilisables dans les dépôts de leur organisation. Visual Studio les détecte automatiquement et affiche leur description ainsi que leur origine dans le sélecteur d'agents. GitHub précise qu'une organisation GitHub est requise pour cette fonction. Source : GitHub.
Fait confirmé. Les modèles pris en charge proposent désormais trois niveaux d'effort de raisonnement : Low, Medium et High. GitHub présente le niveau bas comme adapté aux tâches simples, puis les niveaux supérieurs comme un moyen d'augmenter la profondeur de raisonnement pour le débogage complexe, les algorithmes et les décisions d'architecture. Le même changelog relie ce réglage à l'usage de jetons. Cette formulation compte : GitHub ne promet pas qu'un niveau élevé résoudra un problème, il donne un contrôle supplémentaire sur le compromis entre profondeur et consommation. Source : GitHub.
Fait confirmé. L'interface permet aussi d'épingler des modèles favoris, de masquer ceux qui servent moins souvent et d'ouvrir une vue de gestion. Cette vue présente les capacités des modèles, la taille de leur fenêtre de contexte, des informations de coût et des contrôles pour Copilot et les modèles personnalisés. C'est une information officielle, pas une comparaison indépendante des modèles. Source : GitHub.
Je te conseille de replacer cette annonce dans la continuité des évolutions de Copilot. J'ai regroupé d'autres repères dans mes actualités et dans mon article sur les modèles, plugins et agents GitHub Copilot d'août 2026. Ici, le point distinctif est l'intégration de ces réglages à Visual Studio.
Agents d'organisation : une règle partagée, pas une promesse d'autonomie
Fait confirmé. GitHub indique que les agents personnalisés publiés au niveau organisation ou entreprise peuvent être utilisés à travers les dépôts de cette organisation. Visual Studio les détecte et les identifie dans son sélecteur. L'annonce attribue cette possibilité aux propriétaires d'organisation et d'entreprise. Source : GitHub.
Analyse. Pour une équipe, cela peut réduire la répétition des mêmes consignes dans chaque dépôt. Un agent partagé peut devenir un point de repère pour formuler des demandes cohérentes. Il ne remplace pas, à lui seul, une revue humaine, une convention de code ni une décision de sécurité. La source ne décrit ni la qualité des réponses, ni les autorisations détaillées, ni les règles de gouvernance à adopter. Je ne les déduis donc pas de cette annonce.
Concrètement, si tu administres une organisation GitHub, commence par identifier une consigne récurrente et vérifiable. Un bon premier périmètre serait une aide à la lecture d'un dépôt ou une grille de vérification interne. Évite de traiter l'agent comme une autorité qui valide tout. Avant de généraliser son usage, compare ses suggestions aux pratiques réelles de l'équipe.
Cette logique rejoint mon décryptage des agents IA portables et des agent plugins 1.0. Le mot agent peut recouvrir des mécanismes différents. Ici, l'annonce porte précisément sur des agents personnalisés publiés au niveau de l'organisation dans Visual Studio.
Réglage du raisonnement et gestion des modèles
Fait confirmé. GitHub introduit les niveaux Low, Medium et High pour les modèles pris en charge. Le changelog associe le niveau faible aux demandes directes. Il associe les niveaux plus élevés à des sujets comme le débogage complexe, les algorithmes et l'architecture. Il précise que ce contrôle aide à équilibrer la profondeur de raisonnement et l'utilisation de jetons. Source : GitHub.
Analyse. Ce réglage peut t'inciter à mieux qualifier une demande avant de l'envoyer. Une question précise sur une ligne de code et une investigation sur une architecture ne demandent pas le même effort. C'est une bonne raison de séparer les tâches simples des problèmes ouverts. Ce n'est pas une preuve qu'un réglage élevé apporte systématiquement une meilleure réponse.
En pratique, je garderais une trace minimale de trois éléments : la tâche confiée, le niveau sélectionné et le résultat réellement exploitable. Cette démarche ne mesure pas les performances de Copilot à elle seule. Elle permet simplement d'éviter de choisir un modèle ou un niveau par habitude. Si tu veux approfondir l'effet de la mémoire et des modèles dans un autre IDE, lis aussi mon article sur GitHub Copilot, JetBrains, mémoire et Ollama.
Ce qui reste inconnu. La source fournie ne détaille pas quels modèles sont concernés par chaque niveau de raisonnement. Elle ne donne pas de prix, de seuils d'usage, de mesures de précision ni de calendrier de déploiement plus précis. Elle ne permet pas non plus d'établir une équivalence entre un niveau et une durée, un coût ou une qualité de sortie. Si ces éléments comptent pour ton équipe, il faut les vérifier dans les informations de ton plan et dans l'interface de gestion citée par GitHub.
Pourquoi c’est important
Usage, limites et visibilité dans l'éditeur
Fait confirmé. GitHub indique qu'il est possible d'ouvrir la fenêtre de contexte depuis la zone de prompt Copilot, puis de choisir « View all Copilot usage » pour consulter les détails complets du plan. L'annonce mentionne aussi des notifications affinées lorsque l'utilisateur approche d'une limite et les options disponibles. Source : GitHub.
Analyse. Cette visibilité est utile parce qu'elle rapproche le réglage d'un modèle de la contrainte d'usage. Pour un freelance ou une petite équipe, le réflexe sain consiste à consulter les limites avant de faire dépendre un flux de travail de l'assistant. La présence d'un écran d'usage ne signifie pas que le coût réel d'un projet est connu. Il faut distinguer les informations de plan affichées par l'outil, les conditions contractuelles éventuelles et ton propre temps de validation.
La source précise que la vue de gestion des modèles affiche des informations de coût. Elle ne donne pas ces informations chiffrées dans l'annonce elle-même. Je ne peux donc pas les résumer ni comparer les offres à partir du seul paquet de sources. Même prudence pour les limites : GitHub signale des notifications à l'approche d'une limite, sans fournir ici de seuil universel.
Pour suivre cette actualité dans le temps, tu peux passer par mon blog et la rubrique vidéos. L'enjeu n'est pas de courir après chaque réglage. Il est de comprendre ce qui change dans ton environnement de production avant de modifier une habitude de travail.
La revue de changements par l'agent Git
Fait confirmé. GitHub annonce qu'il est possible de demander à l'agent Git de relire des modifications non validées ou des commits avant l'ouverture d'une pull request. Les constats s'affichent en ligne dans l'éditeur et dans une liste navigable de Git Changes. La conversation Copilot Chat peut ensuite être poursuivie pour comprendre ou traiter chaque suggestion. GitHub indique que cette revue fonctionne avec les dépôts GitHub et Azure DevOps. Source : GitHub.
Analyse. Pour moi, c'est le changement le plus directement actionnable. Une relecture avant la pull request peut aider à rendre visibles des points à examiner plus tôt. Elle ne transforme pas une suggestion en correction. Elle ne prouve pas non plus l'absence de problème dans un commit. La valeur dépendra de la capacité de l'équipe à lire, contester et tester les retours.
Je l'utiliserais comme une étape de préparation, pas comme un feu vert automatique. Tu peux demander une relecture sur un changement ciblé, ouvrir les éléments signalés, puis décider ce qui mérite un test, une correction ou un refus justifié. Cette méthode protège contre deux erreurs opposées : accepter toute suggestion, ou ignorer l'outil parce qu'il ne remplace pas un humain.
Pour élargir ce sujet, consulte mon article sur la revue de code Copilot pour les grandes pull requests. Il faut cependant garder une frontière nette : l'annonce du 28 août concerne la revue par l'agent Git dans Visual Studio et les comportements décrits par GitHub dans ce changelog précis.
Ce que ça change pour toi
Analyse. Si tu codes seul, cette mise à jour te donne surtout trois points de contrôle : le modèle sélectionné, l'effort de raisonnement et la relecture avant pull request. Le bénéfice potentiel est organisationnel. Tu peux rendre ton usage de Copilot moins implicite et mieux adapté au type de tâche.
Si tu travailles en équipe, les agents d'organisation ajoutent un niveau de partage. Le bon usage consiste à définir ce qui doit être commun, puis à vérifier que l'agent reste compréhensible dans le sélecteur. GitHub précise que la description et l'origine de l'organisation sont affichées. C'est utile pour savoir quel agent tu choisis, sans constituer une garantie sur son contenu ou ses effets. Source : GitHub.
Si tu gères un budget logiciel, évite les conclusions rapides. L'annonce confirme une vue avec des informations de coût et des détails de plan. Elle ne fournit pas les tarifs ni une simulation. La conséquence pratique est simple : consulte les données de ton compte avant de changer un processus ou de promettre un volume d'usage à une équipe.
Je vois aussi un intérêt pour les créateurs et entrepreneurs qui construisent un produit avec une petite équipe. La productivité ne vient pas seulement d'un assistant plus présent dans l'éditeur. Elle vient d'une boucle claire : tâche bien posée, niveau d'effort choisi, suggestion relue, changement testé, décision documentée. C'est la même discipline que j'applique aux outils IA présentés sur mon hub principal.
Ce que cela change
Mon avis
Opinion. À mon avis, cette mise à jour est utile parce qu'elle rend plusieurs arbitrages plus visibles dans Visual Studio. Je préfère un outil qui expose ses niveaux de raisonnement, ses modèles et son usage à un automatisme opaque. Je ne considérerais pas les agents partagés ou la revue Git comme des preuves de qualité. Je les traiterais comme des aides qui gagnent leur place après des essais encadrés sur des tâches réelles.
FAQ
Que contient la mise à jour GitHub Copilot pour Visual Studio d'août 2026 ?
GitHub annonce des agents personnalisés d'organisation, des niveaux Low, Medium et High pour les modèles pris en charge, des contrôles de modèles, une vue d'usage et une revue par l'agent Git. Les détails confirmés figurent dans le changelog GitHub.
Quels niveaux de raisonnement sont disponibles dans Copilot pour Visual Studio ?
Pour les modèles pris en charge, GitHub cite trois niveaux : Low, Medium et High. L'annonce les relie au compromis entre profondeur de raisonnement et utilisation de jetons, sans fournir de mesure de performance.
Les agents personnalisés Copilot peuvent-ils être partagés dans une organisation GitHub ?
Oui. GitHub indique que les propriétaires d'organisation et d'entreprise peuvent publier des agents personnalisés utilisables dans les dépôts de leur organisation. Une organisation GitHub est requise selon le changelog.
Peut-on faire relire un commit par Copilot dans Visual Studio ?
GitHub indique que l'agent Git peut relire des modifications non validées ou des commits avant une pull request. Les résultats apparaissent dans l'éditeur et dans Git Changes, pour les dépôts GitHub et Azure DevOps.
Cette mise à jour donne-t-elle les prix ou les limites de GitHub Copilot ?
Non, pas dans la source fournie. GitHub mentionne une vue affichant les détails du plan, les informations de coût et des notifications à l'approche d'une limite, mais l'annonce ne donne aucun tarif ni seuil chiffré.
Information & avertissement
Cet article résume une annonce officielle de GitHub publiée le 28 août 2026. Les faits décrits sont limités à cette source. Mes analyses et mon avis ne remplacent ni la documentation de ton plan GitHub Copilot, ni les vérifications techniques, contractuelles ou de sécurité nécessaires dans ton organisation.
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.
