Productivity | The .NET Blog

VS Code 1.119 : OpenTelemetry pour les sessions d'agents, intégration du navigateur et sécurité

Emiliano Montesdeoca — Fri, 15 May 2026 00:00:00 +0000

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

VS Code 1.119 est sorti le 6 mai 2026 (avec un correctif de sécurité 1.119.1 peu après). La version se concentre sur l’observabilité des agents, l’interaction avec le navigateur et la réduction des interruptions.

Traçage OpenTelemetry pour les sessions d’agents

C’est la fonctionnalité phare pour ceux qui font tourner des agents en production ou qui déboguent des workflows agentiques. Activez-la avec deux paramètres :

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

Les traces suivent les conventions sémantiques GenAI. Chaque requête d’agent produit un span racine invoke_agent avec des spans enfants imbriqués : chat, execute_tool et execute_hook. L’utilisation des tokens est rapportée par requête — y compris les comptages de lecture et de création de cache.

Fonctionne avec l’agent local, l’agent de fond Copilot CLI et l’agent Claude. Tout backend compatible OTLP accepte les traces — le Aspire Dashboard standalone fonctionne bien pour le développement local.

Les agents peuvent maintenant accéder aux onglets du navigateur

Les agents peuvent demander l’accès à vos onglets de navigateur intégré — mais ce n’est pas automatique. Vous devez partager explicitement un onglet via le sélecteur de contexte, le glisser-déposer ou le contexte suggéré. Il y a un bouton de partage dans le navigateur pour révoquer l’accès. Quand un agent tente d’ouvrir un nouvel onglet sur le même domaine qu’un onglet ouvert (non partagé), VS Code vous demande de réutiliser l’onglet existant.

Utilisation optimisée des tokens

Un modèle léger expérimental gère maintenant les listes de tâches des agents, gardant ce travail administratif hors du modèle principal plus coûteux. Réduit la consommation de tokens pour les tâches qui ne nécessitent pas une pleine capacité de raisonnement.

Confiance et sécurité

Moins d’interruptions : VS Code 1.119 réduit les invites pour les demandes d’accès réseau et les écritures dans les dossiers temporaires par les agents. Le correctif 1.119.1 résout des problèmes de sécurité spécifiques — une mise à jour s’impose si ce n’est pas encore fait.

Changement rapide vers l’aperçu Markdown

Petit mais utile : vous pouvez maintenant basculer rapidement l’éditeur actuel vers l’aperçu Markdown sans naviguer.

VS Code Agents (préversion Insiders)

L’interface de session d’agents repensée — nouveau sélecteur de dépôts (local/repos/distant), améliorations des sous-sessions, polissage web et mobile, animations de progression — est disponible dans Insiders sur insiders.vscode.dev/agents.

Journal des modifications complet : code.visualstudio.com/updates/v1_119.

Mise à jour d'avril de Visual Studio 2026 : agent cloud, agents personnalisés et agent débogueur

Emiliano Montesdeoca — Thu, 14 May 2026 00:00:00 +0000

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

La mise à jour d’avril de Visual Studio 2026 (18.5) inclut l’intégration d’agent cloud, des agents personnalisés au niveau utilisateur, les outils C++ passant en GA, et un nouvel Agent Débogueur.

Agent cloud : déléguer le travail à une session Copilot distante

Depuis le sélecteur d’agents dans la fenêtre Chat, sélectionner Cloud permet de confier une tâche à un agent de codage Copilot distant. Vous décrivez le travail, l’agent crée un issue GitHub dans votre dépôt, puis ouvre une PR quand il a terminé. Vous recevez une notification avec “View PR” / “Open in browser” — tout fonctionne pendant que vous continuez à coder, ou même avec l’IDE fermé.

Les agents personnalisés vous accompagnent maintenant partout

Les agents personnalisés au niveau utilisateur stockés dans %USERPROFILE%/.github/agents/ ne sont plus limités à un dépôt — ils vous suivent d’un projet à l’autre. Le chemin de stockage est configurable sous Tools > Options > GitHub > Copilot > Chat. Le bouton + dans le sélecteur d’agents permet de créer directement de nouveaux agents. Ils obtiennent les mêmes capacités que les agents liés à un dépôt : conscience de l’espace de travail, outils, sélection de modèle et connexions MCP.

Agents intégrés : Agent, Ask, Copilot CLI, Debugger, Modernize, Profiler.

Les outils d’édition de code C++ passent en GA

Deux outils — get_symbol_call_hierarchy et get_symbol_class_hierarchy — sont maintenant activés par défaut. Ils donnent à Copilot une navigation consciente du langage dans les bases de code C++, couvrant les hiérarchies d’héritage et les chaînes d’appel de fonctions. Activez via l’icône Tools dans Copilot Chat. Fonctionne mieux avec les modèles d’appel d’outils.

Agent Débogueur : corrections validées contre le comportement réel à l’exécution

Démarrez depuis un issue GitHub ou Azure DevOps (ou une description en langage naturel), passez en mode Debugger, et l’agent :

Crée un reproducteur minimal
Génère des hypothèses de défaillance
Instrumente l’application avec des tracepoints et des breakpoints conditionnels
Lance une vraie session de débogage
Analyse la télémétrie en direct
Suggère un correctif précis

Vous restez dans la boucle tout au long du processus — c’est interactif, pas entièrement autonome.

Correction de priorité IntelliSense

VS supprime désormais les complétions Copilot pendant que la liste IntelliSense est active. Une seule suggestion à la fois. C’était un point de friction fréquent et c’est maintenant activé par défaut.

Notes de version complètes et téléchargement sur devblogs.microsoft.com.

Ce Paramètre de Fenêtres Flottantes de Visual Studio Que Vous Ne Connaissiez Pas (Mais Devriez)

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

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

Si vous utilisez plusieurs écrans avec Visual Studio (et honnêtement, qui ne le fait pas de nos jours ?), vous avez probablement vécu la frustration : les fenêtres d’outils flottantes disparaissent quand vous réduisez l’IDE principal, elles restent toujours au-dessus de tout le reste, et elles n’apparaissent pas comme des boutons séparés dans la barre des tâches. Ça fonctionne pour certains workflows, mais pour les configurations multi-écrans c’est frustrant.

Mads Kristensen de l’équipe Visual Studio a partagé un paramètre peu connu qui change complètement le comportement des fenêtres flottantes. Un menu déroulant. C’est tout.

Le paramètre

Tools > Options > Environment > Windows > Floating Windows

Le menu déroulant “These floating windows are owned by the main window” a trois options :

None — indépendance totale. Chaque fenêtre flottante a sa propre entrée dans la barre des tâches et se comporte comme une fenêtre Windows normale.
Tool Windows (par défaut) — les documents flottent librement, les fenêtres d’outils restent liées à l’IDE.
Documents and Tool Windows — comportement classique de Visual Studio, tout lié à la fenêtre principale.

Pourquoi “None” est le bon choix pour les configurations multi-écrans

Réglez-le sur None et soudain toutes vos fenêtres d’outils et documents flottants se comportent comme de vraies applications Windows. Elles apparaissent dans la barre des tâches, restent visibles quand vous réduisez la fenêtre principale de Visual Studio, et arrêtent de se forcer au premier plan.

Combinez ça avec PowerToys FancyZones et c’est un vrai changement. Créez des dispositions personnalisées sur vos écrans, placez votre Explorateur de Solutions dans une zone, le débogueur dans une autre, et les fichiers de code où vous voulez. Tout reste en place, tout est accessible indépendamment, et votre espace de travail paraît organisé au lieu de chaotique.

Recommandations rapides

Utilisateurs avancés multi-écrans : Réglez sur None, combinez avec FancyZones
Flotteurs occasionnels : Tool Windows (par défaut) est un bon compromis
Workflow traditionnel : Documents and Tool Windows garde tout classique

Astuce pro : Ctrl + double-clic sur la barre de titre de n’importe quelle fenêtre d’outils pour la rendre flottante ou l’ancrer instantanément. Pas besoin de redémarrer après avoir changé le paramètre.

Conclusion

C’est un de ces paramètres du type “je n’arrive pas à croire que je ne connaissais pas ça”. Si les fenêtres flottantes dans Visual Studio vous ont déjà agacé, allez changer ça tout de suite.

Lisez l’article complet pour les détails et les captures d’écran.

Azure DevOps corrige enfin l'éditeur Markdown dont tout le monde se plaignait

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

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

Si vous utilisez Azure Boards, vous avez probablement vécu ça : vous lisez la description d’un work item, peut-être en vérifiant les critères d’acceptation, et vous double-cliquez accidentellement. Boom — vous êtes en mode édition. Vous ne vouliez rien modifier. Vous étiez en train de lire.

Dan Hellem a annoncé le correctif, et c’est un de ces changements qui semblent petits mais qui éliminent une vraie friction de votre workflow quotidien.

Ce qui a changé

L’éditeur Markdown pour les champs texte des work items s’ouvre désormais en mode aperçu par défaut. Vous pouvez lire et interagir avec le contenu — suivre les liens, vérifier le formatage — sans risquer d’entrer accidentellement en mode édition.

Quand vous voulez vraiment éditer, vous cliquez sur l’icône d’édition en haut du champ. Quand vous avez terminé, vous revenez explicitement au mode aperçu. Simple, intentionnel, prévisible.

Pourquoi c’est plus important qu’il n’y paraît

Le fil de feedback communautaire était long. Le comportement de double-clic pour éditer a été introduit avec l’éditeur Markdown en juillet 2025, et les plaintes ont commencé presque immédiatement.

Pour les équipes qui font du sprint planning, du refinement ou du code review avec Azure Boards, ce type de micro-friction s’accumule.

État du déploiement

Ce changement est déjà en cours de déploiement pour un sous-ensemble de clients et s’étendra à tous dans les deux à trois prochaines semaines.

Pour conclure

Toute amélioration n’a pas besoin d’être une fonctionnalité phare. Parfois la meilleure mise à jour consiste simplement à supprimer quelque chose d’agaçant. C’est exactement ça — un petit correctif UX qui rend Azure Boards moins hostile pour les gens qui veulent juste lire leurs work items tranquillement.

Bookmark Studio apporte la navigation par slots et le partage aux signets de Visual Studio

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

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

Les signets dans Visual Studio ont toujours été… corrects. Vous en placez un, vous naviguez au suivant, vous oubliez lequel est lequel. Ça fonctionne, mais ce n’a jamais été une fonctionnalité qu’on qualifierait de puissante.

Mads Kristensen vient de sortir Bookmark Studio, une extension expérimentale qui comble exactement les lacunes que vous avez probablement rencontrées.

Les signets peuvent être assignés aux slots 1–9 et accessibles directement avec Alt+Shift+1 à Alt+Shift+9. Les nouveaux signets obtiennent automatiquement le prochain slot disponible.

Le Gestionnaire de Signets

Une nouvelle fenêtre d’outils affiche tous vos signets avec filtrage par nom, fichier, emplacement, couleur ou slot.

Organisation avec labels, couleurs et dossiers

Les signets peuvent avoir des labels, couleurs et être groupés en dossiers. Toutes les métadonnées sont stockées par solution.

Exporter et partager

Bookmark Studio permet d’exporter les signets en texte brut, Markdown ou CSV.

Signets qui suivent le code

Bookmark Studio suit les signets relativement au texte auquel ils sont ancrés, ils ne dérivent donc pas vers les mauvaises lignes.

Pour conclure

Bookmark Studio ne réinvente rien. Il prend une fonctionnalité qui était « suffisante » depuis des années et la rend vraiment utile. Téléchargez-le depuis le Visual Studio Marketplace.

VS Code 1.112 : Ce qui devrait vraiment intéresser les développeurs .NET

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

VS Code 1.112 vient d’atterrir, et honnêtement ? Celui-ci frappe différemment si vous passez vos journées dans le monde .NET. Il y a beaucoup dans les notes de version officielles, mais laissez-moi vous épargner du défilement et me concentrer sur ce qui nous importe vraiment.

Copilot CLI est devenu bien plus utile

Le grand thème de cette version est l’autonomie de l’agent — donner à Copilot plus de liberté pour faire son travail sans que vous surveilliez chaque étape.

Direction et file d’attente de messages

Vous connaissez ce moment où Copilot CLI est à mi-chemin d’une tâche et vous réalisez que vous avez oublié de mentionner quelque chose ? Avant, vous deviez attendre. Maintenant vous pouvez envoyer des messages pendant qu’une requête est encore en cours — soit pour diriger la réponse actuelle, soit pour mettre en file d’attente des instructions de suivi.

C’est énorme pour ces tâches de scaffolding dotnet plus longues où vous regardez Copilot configurer un projet et pensez “oh attends, j’ai aussi besoin de MassTransit là-dedans.”

Niveaux de permissions

C’est celui qui m’excite le plus. Les sessions Copilot CLI supportent maintenant trois niveaux de permissions :

Permissions par défaut — le flux habituel où les outils demandent confirmation avant d’exécuter
Contourner les approbations — auto-approuve tout et réessaie en cas d’erreur
Autopilote — entièrement autonome : approuve les outils, répond à ses propres questions et continue jusqu’à ce que la tâche soit terminée

Si vous faites quelque chose comme créer une nouvelle API ASP.NET Core avec Entity Framework, des migrations et un setup Docker — le mode Autopilote signifie que vous décrivez ce que vous voulez et allez chercher un café. Il se débrouillera.

Vous pouvez activer l’Autopilote avec le paramètre chat.autopilot.enabled.

Prévisualiser les changements avant délégation

Quand vous déléguez une tâche à Copilot CLI, il crée un worktree. Avant, si vous aviez des changements non commités, vous deviez vérifier le Contrôle de Source pour voir ce qui serait affecté. Maintenant la vue Chat affiche les changements en attente juste là avant que vous décidiez de les copier, déplacer ou ignorer.

Petit détail, mais ça vous évite ce moment “attends, qu’est-ce que j’avais en staging ?”

Déboguez les apps web sans quitter VS Code

Le navigateur intégré supporte maintenant le débogage complet. Vous pouvez placer des breakpoints, parcourir le code pas à pas et inspecter les variables — le tout dans VS Code. Plus besoin de basculer vers Edge DevTools.

Il y a un nouveau type de débogage editor-browser, et si vous avez déjà des configurations de lancement msedge ou chrome, migrer est aussi simple que changer le champ type dans votre launch.json :

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Pour les développeurs Blazor, c’est un game changer. Vous exécutez déjà dotnet watch dans le terminal — maintenant votre débogage reste dans la même fenêtre aussi.

Le navigateur a aussi obtenu des niveaux de zoom indépendants (enfin), des menus contextuels avec clic droit appropriés, et le zoom est mémorisé par site web.

Sandboxing des serveurs MCP

Ceci importe plus que vous ne le pensez. Si vous utilisez des serveurs MCP — peut-être que vous en avez configuré un personnalisé pour vos ressources Azure ou vos requêtes de base de données — ils fonctionnaient avec les mêmes permissions que votre processus VS Code. Ça signifie un accès total à votre système de fichiers, réseau, tout.

Maintenant vous pouvez les sandboxer. Dans votre mcp.json :

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Quand un serveur sandboxé a besoin d’accéder à quelque chose qu’il n’a pas, VS Code vous demande d’accorder la permission. Bien mieux que l’approche “espérons que personne ne fait rien de bizarre”.

Note : Le sandboxing est disponible sur macOS et Linux pour l’instant. Le support Windows arrive — les scénarios distants comme WSL fonctionnent cependant.

Découverte des personnalisations en monorepo

Si vous travaillez dans un monorepo (et soyons honnêtes, beaucoup de solutions .NET d’entreprise finissent par en être un), ça résout un vrai point douloureux.

Avant, si vous ouvriez un sous-dossier de votre repo, VS Code ne trouvait pas votre copilot-instructions.md, AGENTS.md ou vos skills personnalisés situés à la racine du dépôt. Maintenant avec le paramètre chat.useCustomizationsInParentRepositories, il remonte jusqu’à la racine .git et découvre tout.

Ça signifie que votre équipe peut partager des instructions d’agent, des fichiers de prompt et des outils personnalisés entre tous les projets dans un monorepo sans que tout le monde ait à ouvrir le dossier racine.

/troubleshoot pour le débogage d’agents

Vous avez déjà configuré des instructions personnalisées ou des skills et vous vous êtes demandé pourquoi ils ne sont pas détectés ? Le nouveau skill /troubleshoot lit les logs de débogage de l’agent et vous dit ce qui s’est passé — quels outils ont été utilisés ou ignorés, pourquoi les instructions n’ont pas chargé, et ce qui cause des réponses lentes.

Activez-le avec :

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Puis tapez simplement /troubleshoot why is my custom skill not loading? dans le chat.

Vous pouvez aussi exporter et importer ces logs de débogage maintenant, ce qui est super pour les partager avec votre équipe quand quelque chose ne fonctionne pas comme prévu.

Support des fichiers image et binaires

Les agents peuvent maintenant lire les fichiers image depuis le disque et les fichiers binaires nativement. Les fichiers binaires sont présentés au format hexdump, et les sorties image (comme les captures d’écran du navigateur intégré) s’affichent dans une vue carrousel.

Pour les développeurs .NET, pensez : collez une capture d’écran d’un bug UI dans le chat et laissez l’agent comprendre ce qui ne va pas, ou faites-lui analyser la sortie du rendu d’un composant Blazor.

Références de symboles automatiques

Petite amélioration de qualité de vie : quand vous copiez un nom de symbole (une classe, méthode, etc.) et le collez dans le chat, VS Code le convertit maintenant automatiquement en une référence #sym:Name. Ça donne à l’agent le contexte complet sur ce symbole sans que vous ayez à l’ajouter manuellement.

Si vous voulez du texte brut à la place, utilisez Ctrl+Shift+V.

Les plugins peuvent maintenant être activés/désactivés

Avant, désactiver un serveur MCP ou un plugin signifiait le désinstaller. Maintenant vous pouvez les activer et désactiver — globalement et par workspace. Clic droit dans la vue Extensions ou la vue Personnalisations et c’est fait.

Les plugins de npm et pypi peuvent aussi se mettre à jour automatiquement maintenant, bien qu’ils demanderont une approbation d’abord puisque les mises à jour signifient exécuter du nouveau code sur votre machine.

Pour conclure

VS Code 1.112 pousse clairement fort sur l’expérience agent — plus d’autonomie, meilleur débogage, sécurité plus serrée. Pour les développeurs .NET, le débogage du navigateur intégré et les améliorations de Copilot CLI sont les fonctionnalités phares.

Si vous n’avez pas encore essayé de lancer une session Copilot CLI complète en mode Autopilote pour un projet .NET, cette version est un bon moment pour commencer. N’oubliez pas de configurer vos permissions et laissez mijoter.

Télécharger VS Code 1.112 ou mettre à jour depuis VS Code via Aide > Vérifier les mises à jour.

Productivity | The .NET Blog

VS Code 1.119 : OpenTelemetry pour les sessions d'agents, intégration du navigateur et sécurité

Traçage OpenTelemetry pour les sessions d’agents

Les agents peuvent maintenant accéder aux onglets du navigateur

Utilisation optimisée des tokens

Confiance et sécurité

Changement rapide vers l’aperçu Markdown

VS Code Agents (préversion Insiders)

Mise à jour d'avril de Visual Studio 2026 : agent cloud, agents personnalisés et agent débogueur

Agent cloud : déléguer le travail à une session Copilot distante

Les agents personnalisés vous accompagnent maintenant partout

Les outils d’édition de code C++ passent en GA

Agent Débogueur : corrections validées contre le comportement réel à l’exécution

Correction de priorité IntelliSense

Ce Paramètre de Fenêtres Flottantes de Visual Studio Que Vous Ne Connaissiez Pas (Mais Devriez)

Le paramètre

Pourquoi “None” est le bon choix pour les configurations multi-écrans

Recommandations rapides

Conclusion

Azure DevOps corrige enfin l'éditeur Markdown dont tout le monde se plaignait

Ce qui a changé

Pourquoi c’est plus important qu’il n’y paraît

État du déploiement

Pour conclure

Bookmark Studio apporte la navigation par slots et le partage aux signets de Visual Studio

Navigation par slots

Le Gestionnaire de Signets

Organisation avec labels, couleurs et dossiers

Exporter et partager

Signets qui suivent le code

Pour conclure

VS Code 1.112 : Ce qui devrait vraiment intéresser les développeurs .NET

Copilot CLI est devenu bien plus utile

Direction et file d’attente de messages

Niveaux de permissions

Prévisualiser les changements avant délégation

Déboguez les apps web sans quitter VS Code

Sandboxing des serveurs MCP

Découverte des personnalisations en monorepo

/troubleshoot pour le débogage d’agents

Support des fichiers image et binaires

Références de symboles automatiques

Les plugins peuvent maintenant être activés/désactivés

Pour conclure