GitHub Copilot | The .NET Blog

Mise à Jour Avril du Azure DevOps MCP Server : Requêtes WIQL, Auth PAT et MCP Apps Expérimentales

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Le Azure DevOps MCP Server s’améliore continuellement. La mise à jour d’avril couvre les deux serveurs.

Support des Requêtes WIQL

Le nouvel outil wit_query_by_wiql permet d’exécuter des requêtes Work Item Query Language depuis votre client MCP.

Personal Access Tokens

Authentification PAT sur le serveur local — important pour les scénarios d’intégration sans authentification interactive.

Annotations MCP

Métadonnées pour les outils en lecture seule, destructifs et open-world — fondamentaux pour la fiabilité des agents.

Consolidation des Outils Wiki

5 outils wiki séparés → 2 outils plus capables. Moins d’outils = meilleure performance LLM.

Expérimental : MCP Apps

Workflows packagés dans l’environnement du serveur MCP. La direction est bonne.

Post original de Dan Hellem : Azure DevOps MCP Server April Update.

VS Code 1.118 : Copilot CLI obtient des noms de session, des badges de modèle et TypeScript 7.0 Nightly

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

Visual Studio Code 1.118 est une version plus petite et ciblée — principalement des raffinements de Copilot CLI — mais quelques éléments méritent d’être notés.

Copilot CLI : les sessions ont de vrais noms

Les APIs de titre de session du SDK Copilot CLI servent maintenant de source de vérité pour les noms de session. Les sessions affichent désormais le vrai nom du SDK au lieu d’étiquettes générées automatiquement.

Changer de session plus rapidement

L’application Agents a maintenant Ctrl+1, Ctrl+2, etc. pour basculer rapidement entre les sessions.

Badges de modèle dans le chat

Les réponses Copilot CLI dans le panneau de chat affichent maintenant un badge de modèle pour voir quel modèle a traité chaque requête.

Sélection automatique de modèle dans Copilot CLI

La sélection automatique de modèle fonctionne maintenant aussi dans l’agent Copilot CLI.

Opt-in TypeScript 7.0 Nightly

Vous pouvez maintenant tester les nightlies TypeScript 7.0 directement depuis les paramètres VS Code. TypeScript 7.0 est une version majeure (la bêta est sortie il y a quelques jours).

Consultez les notes de version complètes.

68 Minutes par Jour à Ré-Expliquer Son Code ? Il Y a une Solution

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Vous connaissez ce moment où votre session Copilot atteint /compact et que l’agent oublie complètement ce sur quoi vous travailliez ? Vous passez les cinq minutes suivantes à ré-expliquer la structure des fichiers, le test qui échoue, les trois approches déjà essayées. Puis ça recommence.

Desi Villanueva l’a chronométré : 68 minutes par jour — juste pour la réorientation. Pas à écrire du code. Pas à revoir des PRs. Juste à remettre l’IA au courant de choses qu’elle savait déjà.

Il s’avère qu’il y a une raison concrète à cela — et une solution concrète.

Le Mensonge de la Fenêtre de Contexte

Votre agent arrive avec un grand nombre sur la boîte. 200K tokens. Ça semble massif. En pratique c’est un plafond, pas une garantie.

Voici le calcul réel :

200K contexte total
Moins ~65K pour les outils MCP chargés au démarrage (~33%)
Moins ~10K pour les fichiers d’instructions comme AGENTS.md

Cela vous laisse environ 125K avant d’avoir tapé un seul mot. Et ça empire — les LLMs ne se dégradent pas gracieusement. Ils atteignent un mur vers 60% d’utilisation. Le modèle commence à perdre des éléments mentionnés 30 tours plus tôt.

Limite effective : 45K tokens avant que la qualité se dégrade.

La Taxe de Compactage

Chaque /compact vous coûte votre état de flow. Vous êtes profondément dans une session de débogage. Contexte partagé construit sur 30 minutes. Puis l’avertissement arrive.

La partie cruelle : La mémoire existe déjà. Copilot CLI écrit chaque session dans une base de données SQLite locale à ~/.copilot/session-store.db. L’agent ne peut tout simplement pas la lire.

auto-memory : Une Couche de Rappel, Pas un Système de Mémoire

pip install auto-memory

~1 900 lignes de Python. Zéro dépendances. Installé en 30 secondes.

Au lieu d’inonder le contexte avec des résultats grep, vous donnez à l’agent un accès chirurgical à ce qui compte vraiment — 50 tokens au lieu de 10 000.

En Conclusion

Le context rot est une contrainte architecturale réelle. auto-memory le contourne en donnant à votre agent un mécanisme de rappel bon marché et précis.

Consultez-le : auto-memory sur GitHub. Post original de Desi Villanueva : I Wasted 68 Minutes a Day.

azd + GitHub Copilot : Configuration de projet assistée par IA et résolution intelligente des erreurs

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale en anglais, clique ici.

Tu connais ce moment où tu veux déployer une app existante sur Azure et tu te retrouves à fixer un azure.yaml vide, en essayant de te rappeler si ton API Express devrait utiliser Container Apps ou App Service ? Ce moment vient de devenir beaucoup plus court.

L’Azure Developer CLI (azd) s’intègre maintenant avec GitHub Copilot de deux façons concrètes : scaffolding assisté par IA pendant azd init, et résolution intelligente des erreurs quand les déploiements échouent. Les deux fonctionnalités restent entièrement dans ton terminal — exactement là où je veux qu’elles soient.

Configuration avec Copilot pendant azd init

Quand tu lances azd init, il y a maintenant une option “Set up with GitHub Copilot (Preview)”. Sélectionne-la et Copilot analyse ta base de code pour générer l’azure.yaml, les templates d’infrastructure et les modules Bicep — basés sur ton code réel.

azd init
# Sélectionne : "Set up with GitHub Copilot (Preview)"

Prérequis :

azd 1.23.11 ou supérieur — vérifie avec azd version ou mets à jour avec azd update
Un abonnement GitHub Copilot actif (Individual, Business ou Enterprise)
GitHub CLI (gh) — azd demandera la connexion si nécessaire

Ce que je trouve vraiment utile : ça fonctionne dans les deux sens. Tu construis depuis zéro ? Copilot t’aide à configurer les bons services Azure dès le départ. Tu as une app existante que tu voulais déployer depuis longtemps ? Pointe Copilot dessus et il génère la configuration sans que tu aies à restructurer quoi que ce soit.

Ce que ça fait concrètement

Imaginons une API Express Node.js avec une dépendance PostgreSQL. Au lieu de décider manuellement entre Container Apps et App Service, puis d’écrire du Bicep depuis zéro, Copilot détecte ton stack et génère :

Un azure.yaml avec les bons paramètres language, host et build
Un module Bicep pour Azure Container Apps
Un module Bicep pour Azure Database for PostgreSQL

Et il effectue des vérifications préalables avant de toucher quoi que ce soit — vérifie que ton répertoire git est propre, demande le consentement pour les outils du serveur MCP. Rien ne se passe sans que tu saches exactement ce qui va changer.

Résolution d’erreurs avec Copilot

Les erreurs de déploiement, ça arrive. Paramètres manquants, problèmes de permissions, disponibilité des SKUs — et le message d’erreur ne te dit rarement la seule chose dont tu as vraiment besoin : comment régler le problème.

Sans Copilot, la boucle ressemble à : copier l’erreur → chercher dans la doc → lire trois réponses Stack Overflow hors sujet → exécuter quelques commandes az CLI → réessayer en espérant que ça marche. Avec Copilot intégré dans azd, cette boucle s’effondre. Quand une commande azd échoue, elle propose immédiatement quatre options :

Explain — explication en langage naturel de ce qui s’est passé
Guidance — instructions étape par étape pour corriger le problème
Diagnose and Guide — analyse complète + Copilot applique le correctif (avec ton approbation) + nouvelle tentative optionnelle
Skip — gérer toi-même

L’essentiel : Copilot a déjà le contexte de ton projet, la commande qui a échoué et les détails de l’erreur. Ses suggestions sont spécifiques à ta situation, pas de la documentation générique.

Configurer un comportement par défaut

Si tu choisis toujours la même option, saute le prompt interactif :

azd config set copilot.errorHandling.category troubleshoot

Valeurs : explain, guidance, troubleshoot, fix, skip. Tu peux aussi activer l’auto-fix et le retry :

azd config set copilot.errorHandling.fix allow

Retour au mode interactif à tout moment :

azd config unset copilot.errorHandling.category

Conclusion

C’est exactement le type d’intégration Copilot qui apporte une vraie valeur. Essaie-le en lançant azd update pour obtenir la dernière version, puis utilise azd init sur ton prochain projet.

Lis l’annonce originale ici.

VS Code 1.117 : Les Agents Obtiennent Leurs Propres Branches Git et Je Suis Totalement Pour

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

La frontière entre « assistant IA » et « coéquipier IA » continue de s’amincir. VS Code 1.117 vient de sortir et les notes de version complètes sont bien remplies, mais l’histoire est claire : les agents deviennent des citoyens de première classe dans votre workflow de développement.

Voici ce qui compte vraiment.

Le mode Autopilot se souvient enfin de votre préférence

Avant, il fallait réactiver Autopilot à chaque nouvelle session. Agaçant. Maintenant votre mode de permissions persiste d’une session à l’autre, et vous pouvez configurer la valeur par défaut.

L’Agent Host supporte trois configurations de session :

Default — les outils demandent confirmation avant de s’exécuter
Bypass — approuve tout automatiquement
Autopilot — totalement autonome, répond à ses propres questions et continue

Si vous construisez un nouveau projet .NET avec des migrations, Docker et de la CI — réglez-le sur Autopilot une fois et oubliez-le. Cette préférence reste.

Worktree et isolation git pour les sessions d’agents

C’est le gros morceau. Les sessions d’agents supportent maintenant l’isolation complète par worktree et git. Cela signifie que quand un agent travaille sur une tâche, il obtient sa propre branche et son propre répertoire de travail. Votre branche principale reste intacte.

Encore mieux — Copilot CLI génère des noms de branche significatifs pour ces sessions worktree. Fini le agent-session-abc123. Vous obtenez quelque chose qui décrit réellement ce que l’agent fait.

Pour les développeurs .NET qui gèrent plusieurs branches de fonctionnalités ou corrigent des bugs pendant qu’une longue tâche de scaffolding tourne, c’est un vrai changement. Vous pouvez avoir un agent qui construit vos contrôleurs d’API dans un worktree pendant que vous déboguez un problème dans la couche de services dans un autre. Pas de conflits. Pas de stashing. Pas de bazar.

Sous-agents et équipes d’agents

L’Agent Host Protocol supporte maintenant les sous-agents. Un agent peut lancer d’autres agents pour gérer des parties d’une tâche. Pensez-y comme de la délégation — votre agent principal coordonne, et des agents spécialisés s’occupent des morceaux.

C’est encore tôt, mais le potentiel pour les workflows .NET est évident. Imaginez un agent qui gère vos migrations EF Core pendant qu’un autre configure vos tests d’intégration. On n’y est pas encore complètement, mais le fait que le support du protocole arrive maintenant signifie que l’outillage suivra rapidement.

La sortie terminal automatiquement incluse quand les agents envoient de l’input

Petit mais significatif. Quand un agent envoie de l’input au terminal, la sortie du terminal est maintenant automatiquement incluse dans le contexte. Avant, l’agent devait faire un tour supplémentaire juste pour lire ce qui s’était passé.

Si vous avez déjà vu un agent exécuter dotnet build, échouer, puis faire un aller-retour supplémentaire juste pour voir l’erreur — cette friction a disparu. Il voit la sortie immédiatement et réagit.

L’application Agents sur macOS se met à jour automatiquement

L’application autonome Agents sur macOS se met maintenant à jour automatiquement. Plus besoin de télécharger manuellement les nouvelles versions. Elle reste simplement à jour.

Les petites choses qui valent la peine d’être connues

Les survols package.json affichent maintenant la version installée et la dernière disponible. Utile si vous gérez des outils npm aux côtés de vos projets .NET.
Les images dans les commentaires JSDoc s’affichent correctement dans les survols et les complétions.
Les sessions Copilot CLI indiquent maintenant si elles ont été créées par VS Code ou en externe — pratique quand vous sautez entre les terminaux.
Copilot CLI, Claude Code et Gemini CLI sont reconnus comme types de shell. L’éditeur sait ce que vous exécutez.

Ce qu’il faut retenir

VS Code 1.117 n’est pas un déversement de fonctionnalités tape-à-l’œil. C’est de l’infrastructure. Isolation par worktree, permissions persistantes, protocoles de sous-agents — ce sont les briques pour un workflow où les agents gèrent des tâches réelles et parallèles sans marcher sur votre code.

Si vous développez avec .NET et que vous ne vous êtes pas encore lancé dans le workflow agentique, honnêtement, c’est le moment de commencer.

Docker Sandbox permet aux agents Copilot de refactoriser votre code sans risque pour votre machine

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si vous avez utilisé le mode agent de Copilot pour autre chose que de petites modifications, vous connaissez la douleur. Chaque écriture de fichier, chaque commande terminal — encore une demande de permission. Maintenant, imaginez ça sur 50 projets. Pas vraiment fun.

L’équipe Azure vient de publier un article sur Docker Sandbox pour les agents GitHub Copilot, et honnêtement, c’est l’une des améliorations les plus pratiques que j’ai vues dans l’outillage agentique. Le système utilise des microVMs pour donner à Copilot un environnement totalement isolé où il peut faire ce qu’il veut — installer des paquets, lancer des builds, exécuter des tests — sans toucher à votre système hôte.

Ce que Docker Sandbox vous apporte concrètement

L’idée de base est simple : démarrer une microVM légère avec un environnement Linux complet, synchroniser votre workspace dedans, et laisser l’agent Copilot opérer librement à l’intérieur. Quand il a terminé, les modifications sont synchronisées en retour.

Voici ce qui en fait plus qu’un simple “exécuter des trucs dans un conteneur” :

Synchronisation bidirectionnelle du workspace qui préserve les chemins absolus. La structure de votre projet est identique à l’intérieur du sandbox. Pas d’échecs de build liés aux chemins.
Docker daemon privé tournant à l’intérieur de la microVM. L’agent peut construire et exécuter des conteneurs sans jamais monter le socket Docker de votre hôte. C’est un gros plus pour la sécurité.
Proxies de filtrage HTTP/HTTPS qui contrôlent ce que l’agent peut atteindre sur le réseau. Vous décidez quels registries et endpoints sont autorisés. Des attaques de supply chain via un npm install malveillant dans le sandbox ? Bloquées.
Mode YOLO — oui, c’est vraiment comme ça qu’ils l’appellent. L’agent tourne sans demandes de permission parce qu’il ne peut littéralement pas endommager votre hôte. Toute action destructrice est contenue.

Pourquoi les développeurs .NET devraient s’y intéresser

Pensez au travail de modernisation auquel tant d’équipes font face en ce moment. Vous avez une solution .NET Framework avec 30 projets, et vous devez la migrer vers .NET 9. Ce sont des centaines de modifications de fichiers — fichiers de projet, mises à jour de namespaces, remplacements d’API, migrations NuGet.

Avec Docker Sandbox, vous pouvez pointer un agent Copilot sur un projet, le laisser refactoriser librement dans la microVM, exécuter dotnet build et dotnet test pour valider, et n’accepter que les changements qui fonctionnent réellement. Aucun risque qu’il détruise accidentellement votre environnement de développement local en expérimentant.

L’article décrit également l’exécution d’une flotte d’agents en parallèle — chacun dans son propre sandbox — s’attaquant à différents projets simultanément. Pour les grandes solutions .NET ou les architectures microservices, c’est un gain de temps massif. Un agent par service, tous isolés, tous validés indépendamment.

L’angle sécurité compte

Voici ce que la plupart des gens ignorent : quand vous laissez un agent IA exécuter des commandes arbitraires, vous lui confiez l’intégralité de votre machine. Docker Sandbox inverse ce modèle. L’agent obtient une autonomie totale dans un environnement jetable. Le proxy réseau garantit qu’il ne peut télécharger que depuis des sources approuvées. Votre système de fichiers hôte, votre Docker daemon et vos identifiants restent intacts.

Pour les équipes avec des exigences de conformité — et c’est le cas de la plupart des entreprises .NET — c’est la différence entre “on ne peut pas utiliser l’IA agentique” et “on peut l’adopter en toute sécurité.”

À retenir

Docker Sandbox résout la tension fondamentale du coding agentique : les agents ont besoin de liberté pour être utiles, mais la liberté sur votre machine hôte est dangereuse. Les microVMs vous offrent les deux. Si vous planifiez un refactoring ou une modernisation .NET à grande échelle, ça vaut le coup de le mettre en place maintenant. La combinaison de l’intelligence de code de Copilot avec un environnement d’exécution sécurisé est exactement ce que les équipes de production attendaient.

L'évaluation de modernisation de GitHub Copilot est le meilleur outil de migration que vous n'utilisez pas encore

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Migrer une application legacy .NET Framework vers .NET moderne est l’une de ces tâches que tout le monde sait devoir faire mais que personne ne veut commencer. Ce n’est jamais juste « changer le framework cible ». Ce sont des API qui ont disparu, des packages qui n’existent plus, des modèles d’hébergement qui fonctionnent totalement différemment, et un million de petites décisions sur ce qu’il faut containeriser, réécrire ou laisser tel quel.

Jeffrey Fritz vient de publier une plongée approfondie dans l’évaluation de modernisation de GitHub Copilot, et honnêtement ? C’est le meilleur outillage de migration que j’ai vu pour .NET. Pas à cause de la génération de code — c’est devenu standard maintenant. À cause du document d’évaluation qu’il produit.

Ce n’est pas qu’un moteur de suggestions de code

L’extension VS Code suit un modèle Évaluer → Planifier → Exécuter. La phase d’évaluation analyse l’intégralité de votre codebase et produit un document structuré qui capture tout : ce qui doit changer, quelles ressources Azure provisionner, quel modèle de déploiement utiliser. Tout en aval — infrastructure as code, containerisation, manifestes de déploiement — découle de ce que l’évaluation trouve.

L’évaluation est stockée sous .github/modernize/assessment/ dans votre projet. Chaque exécution produit un rapport indépendant, vous construisez ainsi un historique et pouvez suivre l’évolution de votre posture de migration au fur et à mesure que vous corrigez les issues.

Deux façons de commencer

Évaluation Recommandée — la voie rapide. Choisissez parmi des domaines curatés (Mise à jour Java/.NET, Cloud Readiness, Sécurité) et obtenez des résultats significatifs sans toucher à la configuration. Idéal pour un premier regard sur l’état de votre application.

Évaluation Personnalisée — la voie ciblée. Configurez exactement ce qu’il faut analyser : compute cible (App Service, AKS, Container Apps), OS cible, analyse de containerisation. Choisissez plusieurs cibles Azure pour comparer les approches de migration côte à côte.

Cette vue de comparaison est véritablement utile. Une app avec 3 issues obligatoires pour App Service pourrait en avoir 7 pour AKS. Voir les deux aide à prendre la décision d’hébergement avant de s’engager sur un chemin de migration.

Le détail des issues est actionnable

Chaque issue est accompagné d’un niveau de criticité :

Obligatoire — doit être corrigé sinon la migration échoue
Potentiel — pourrait impacter la migration, nécessite un jugement humain
Optionnel — améliorations recommandées, ne bloque pas la migration

Et chaque issue renvoie aux fichiers affectés et numéros de lignes, fournit une description détaillée de ce qui ne va pas et pourquoi c’est important pour votre plateforme cible, donne des étapes concrètes de remédiation (pas juste « corrigez ceci ») et inclut des liens vers la documentation officielle.

Vous pouvez confier des issues individuelles à des développeurs et ils ont tout ce dont ils ont besoin pour agir. C’est la différence entre un outil qui vous dit « il y a un problème » et un qui vous dit comment le résoudre.

Les chemins de mise à jour couverts

Pour .NET spécifiquement :

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Chaque chemin de mise à jour a des règles de détection qui savent quelles API ont été supprimées, quels patterns n’ont pas d’équivalent direct et quels problèmes de sécurité nécessitent une attention particulière.

Pour les équipes gérant plusieurs applications, il y a aussi un CLI qui supporte les évaluations batch multi-repo — clonez tous les repos, évaluez-les tous, obtenez des rapports par application plus une vue agrégée du portfolio.

Mon avis

Si vous êtes assis sur des applications legacy .NET Framework (et soyons honnêtes, la plupart des équipes enterprise le sont), c’est l’outil par lequel commencer. Le document d’évaluation seul vaut le temps — il transforme un vague « on devrait moderniser » en une liste concrète et priorisée d’éléments de travail avec des chemins clairs vers l’avant.

Le workflow collaboratif est malin aussi : exportez les évaluations, partagez-les avec votre équipe, importez-les sans relancer. Revues d’architecture où les décideurs ne sont pas ceux qui exécutent les outils ? Couvert.

Pour conclure

L’évaluation de modernisation de GitHub Copilot transforme la migration .NET d’un projet effrayant et indéfini en un processus structuré et traçable. Commencez avec une évaluation recommandée pour voir où vous en êtes, puis utilisez des évaluations personnalisées pour comparer les cibles Azure et construire votre plan de migration.

Lisez le walkthrough complet et récupérez l’extension VS Code pour l’essayer sur votre propre codebase.

L'Ingénierie de Plateformes Agentique Devient Réalité — Git-APE Montre Comment

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

L’ingénierie de plateformes est un de ces termes qui sonne bien en conférence mais qui signifie généralement « on a construit un portail interne et un wrapper Terraform. » La vraie promesse — une infrastructure en self-service qui soit réellement sécurisée, gouvernée et rapide — a toujours été à quelques pas.

L’équipe Azure vient de publier la Partie 2 de leur série sur l’ingénierie de plateformes agentique, et celle-ci porte sur l’implémentation concrète. Ils l’appellent Git-APE (oui, l’acronyme est intentionnel), et c’est un projet open source qui utilise les agents GitHub Copilot plus les serveurs Azure MCP pour transformer des requêtes en langage naturel en infrastructure validée et déployée.

Ce que Git-APE fait concrètement

L’idée principale : au lieu que les développeurs apprennent des modules Terraform, naviguent dans des UIs de portails ou déposent des tickets à l’équipe plateforme, ils parlent à un agent Copilot. L’agent interprète l’intention, génère de l’Infrastructure-as-Code, la valide contre les politiques et déploie — le tout dans VS Code.

Voici la mise en place :

git clone https://github.com/Azure/git-ape
cd git-ape

Ouvre le workspace dans VS Code, et les fichiers de configuration de l’agent sont automatiquement découverts par GitHub Copilot. Tu interagis directement avec l’agent :

@git-ape deploy a function app with storage in West Europe

L’agent utilise Azure MCP Server en interne pour interagir avec les services Azure. La configuration MCP dans les paramètres de VS Code active des capacités spécifiques :

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Pourquoi c’est important

Pour ceux d’entre nous qui construisent sur Azure, cela déplace la conversation de l’ingénierie de plateformes de « comment construire un portail » à « comment décrire nos garde-fous comme des APIs. » Quand l’interface de ta plateforme est un agent IA, la qualité de tes contraintes et politiques devient le produit.

Le blog de la Partie 1 posait la théorie : des APIs bien décrites, des schémas de contrôle et des garde-fous explicites rendent les plateformes agent-ready. La Partie 2 prouve que ça marche en livrant des outils concrets. L’agent ne génère pas aveuglément des ressources — il valide contre les bonnes pratiques, respecte les conventions de nommage et applique les politiques de ton organisation.

Le nettoyage est tout aussi simple :

@git-ape destroy my-resource-group

Mon avis

Je serai honnête — ici c’est plus le pattern que l’outil spécifique qui compte. Git-APE lui-même est une démo/architecture de référence. Mais l’idée sous-jacente — les agents comme interface de ta plateforme, MCP comme protocole, GitHub Copilot comme hôte — c’est la direction que prend l’expérience développeur en entreprise.

Si tu es une équipe plateforme qui cherche comment rendre son outillage interne agent-friendly, il n’y a pas de meilleur point de départ. Et si tu es un développeur .NET qui se demande comment ça se connecte à ton monde : Azure MCP Server et les agents GitHub Copilot fonctionnent avec n’importe quel workload Azure. Ton API ASP.NET Core, ton stack .NET Aspire, tes microservices containerisés — tout ça peut être la cible d’un flux de déploiement agentique.

Pour conclure

Git-APE est un aperçu précoce mais concret de l’ingénierie de plateformes agentique en pratique. Clone le repo, essaie la démo et commence à réfléchir à comment les APIs et politiques de ta plateforme devraient se présenter pour qu’un agent puisse les utiliser en toute sécurité.

Lis le post complet pour le walkthrough et les vidéos de démo.

La mise à jour de mars de Visual Studio permet de créer des agents Copilot personnalisés — et find_symbol est révolutionnaire

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Visual Studio vient de recevoir sa mise à jour Copilot la plus significative. Mark Downie a annoncé la version de mars, et le titre principal concerne les agents personnalisés — mais honnêtement, l’outil find_symbol pourrait être la fonctionnalité qui change le plus votre workflow.

Agents Copilot personnalisés dans votre repo

Envie que Copilot suive les standards de code de votre équipe ? Les agents personnalisés sont définis comme des fichiers .agent.md dans .github/agents/. Chaque agent a un accès complet au workspace, à la compréhension du code, aux outils, votre modèle préféré et aux connexions MCP.

Agent skills : packs d’instructions réutilisables

Les skills sont chargés automatiquement depuis .github/skills/ dans votre repo ou ~/.copilot/skills/ dans votre profil.

Le nouvel outil find_symbol donne au mode agent de Copilot une navigation de symboles basée sur les services de langage. Au lieu de chercher du texte, l’agent peut trouver toutes les références d’un symbole et accéder aux informations de type et de portée.

Pour les développeurs .NET, c’est une amélioration massive — les bases de code C# avec des hiérarchies de types profondes en bénéficient énormément.

Profiler des tests avec Copilot

Il y a un nouveau Profile with Copilot dans le menu contextuel du Test Explorer. Le Profiling Agent exécute le test et analyse automatiquement les performances.

Perf tips pendant le débogage en direct

L’optimisation des performances se fait maintenant pendant le débogage. Visual Studio affiche le temps d’exécution inline. Ligne lente ? Cliquez sur le Perf Tip et demandez à Copilot des suggestions.

Corriger les vulnérabilités NuGet depuis Solution Explorer

Un lien Fix with GitHub Copilot apparaît directement dans Solution Explorer quand une vulnérabilité est détectée.

Pour conclure

Les agents personnalisés et les skills font le titre, mais find_symbol est la pépite cachée — il change fondamentalement la précision de Copilot lors du refactoring de code .NET. Téléchargez Visual Studio 2026 Insiders pour tout essayer.

GitHub Copilot | The .NET Blog

Mise à Jour Avril du Azure DevOps MCP Server : Requêtes WIQL, Auth PAT et MCP Apps Expérimentales

Support des Requêtes WIQL

Personal Access Tokens

Annotations MCP

Consolidation des Outils Wiki

Expérimental : MCP Apps

VS Code 1.118 : Copilot CLI obtient des noms de session, des badges de modèle et TypeScript 7.0 Nightly

Copilot CLI : les sessions ont de vrais noms

Changer de session plus rapidement

Badges de modèle dans le chat

Sélection automatique de modèle dans Copilot CLI

Opt-in TypeScript 7.0 Nightly

68 Minutes par Jour à Ré-Expliquer Son Code ? Il Y a une Solution

Le Mensonge de la Fenêtre de Contexte

La Taxe de Compactage

auto-memory : Une Couche de Rappel, Pas un Système de Mémoire

En Conclusion

azd + GitHub Copilot : Configuration de projet assistée par IA et résolution intelligente des erreurs

Configuration avec Copilot pendant azd init

Ce que ça fait concrètement

Résolution d’erreurs avec Copilot

Configurer un comportement par défaut

Conclusion

VS Code 1.117 : Les Agents Obtiennent Leurs Propres Branches Git et Je Suis Totalement Pour

Le mode Autopilot se souvient enfin de votre préférence

Worktree et isolation git pour les sessions d’agents

Sous-agents et équipes d’agents

La sortie terminal automatiquement incluse quand les agents envoient de l’input

L’application Agents sur macOS se met à jour automatiquement

Les petites choses qui valent la peine d’être connues

Ce qu’il faut retenir

Docker Sandbox permet aux agents Copilot de refactoriser votre code sans risque pour votre machine

Ce que Docker Sandbox vous apporte concrètement

Pourquoi les développeurs .NET devraient s’y intéresser

L’angle sécurité compte

À retenir

L'évaluation de modernisation de GitHub Copilot est le meilleur outil de migration que vous n'utilisez pas encore

Ce n’est pas qu’un moteur de suggestions de code

Deux façons de commencer

Le détail des issues est actionnable

Les chemins de mise à jour couverts

Mon avis

Pour conclure

L'Ingénierie de Plateformes Agentique Devient Réalité — Git-APE Montre Comment

Ce que Git-APE fait concrètement

Pourquoi c’est important

Mon avis

Pour conclure

La mise à jour de mars de Visual Studio permet de créer des agents Copilot personnalisés — et find_symbol est révolutionnaire

Agents Copilot personnalisés dans votre repo

Agent skills : packs d’instructions réutilisables

find_symbol : navigation consciente du langage

Profiler des tests avec Copilot

Perf tips pendant le débogage en direct

Corriger les vulnérabilités NuGet depuis Solution Explorer

Pour conclure