Developer Tools | 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.

Azure Data Studio est retraité : migrez votre flux Azure SQL vers VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

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

Azure Data Studio a été retraité le 6 février 2025, le support se termine le 28 février 2026 — le remplacement recommandé est VS Code avec l’extension MSSQL.

Ce qu’il faut installer

Trois éléments pour commencer :

Extension MSSQL — cherchez « SQL Server (mssql) » dans le Marketplace VS Code
Extension SQL Database Projects — schéma en tant que code, validation de build, publication guidée
.NET 8 SDK — requis par le système de build ; SDK manquant est le problème le plus fréquent au premier démarrage

Migrer vos connexions et paramètres ADS

L’extension MSSQL inclut l’ADS Migration Toolkit, qui gère la migration unique dans un flux guidé : connexions enregistrées, groupes de connexions, paramètres et raccourcis clavier sont tous importés automatiquement.

Retrouver le réflexe F5

Les utilisateurs d’ADS utilisent F5 pour exécuter des requêtes. Installez l’extension MSSQL Database Management Keymap pour retrouver les raccourcis clavier de type ADS, y compris F5.

SQL Database Projects : schéma en tant que code

Clic droit sur un projet → Publier → configurer la cible → examiner le script T-SQL généré → déployer. La prévisualisation du script avant le déploiement est la fonctionnalité de sécurité clé. Les modèles d’éléments génèrent des stubs pour les tables, procédures stockées et vues — le même flux de travail que SSDT.

Problème courant : une incompatibilité de plateforme cible dans le fichier .sqlproj provoquera des erreurs de build si le projet a été créé pour une version différente de SQL Server.

Schema Compare et Schema Designer

L’extension inclut également Schema Compare (diff entre votre projet et la base de données déployée) et Schema Designer (édition visuelle du schéma sans écrire du DDL à la main).

Développeurs Microsoft Fabric

La configuration est identique, mais commencez depuis le portail Fabric et connectez la base de données à Git avant de l’ouvrir dans VS Code. Microsoft dispose d’un guide dédié : Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

En résumé

La migration est un flux guidé en une seule fois, pas une reconstruction manuelle. Installez les trois outils, exécutez l’ADS Migration Toolkit, restaurez vos raccourcis clavier, et vous êtes de retour à la normale en moins de 10 minutes.

Consultez l’article complet pour les captures d’écran étape par étape et le tutoriel spécifique à Fabric.

Azure MCP Server Est Maintenant un .mcpb — Installez-le sans Aucun Runtime

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

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

Vous savez ce qui était pénible dans la configuration des serveurs MCP ? Vous aviez besoin d’un runtime. Node.js pour la version npm, Python pour pip/uvx, .NET SDK pour la variante dotnet.

L’Azure MCP Server vient de changer cela. Il est maintenant disponible en tant que .mcpb — un MCP Bundle — et la configuration se fait par glisser-déposer.

Qu’est-ce qu’un MCP Bundle ?

Pensez-y comme à une extension VS Code (.vsix) ou une extension de navigateur (.crx), mais pour les serveurs MCP. Un fichier .mcpb est une archive ZIP autonome incluant le binaire du serveur et toutes ses dépendances.

Comment l’installer

1. Téléchargez le bundle pour votre plateforme

Allez sur la page GitHub Releases et téléchargez le fichier .mcpb pour votre OS et architecture.

2. Installez dans Claude Desktop

Le plus simple : faites glisser le fichier .mcpb dans la fenêtre Claude Desktop sur la page des paramètres Extensions (☰ → Fichier → Paramètres → Extensions). Vérifiez les détails du serveur, cliquez sur Installer, confirmez.

3. Authentifiez-vous auprès d’Azure

az login

C’est tout. Azure MCP Server utilise vos identifiants Azure existants.

Ce que vous pouvez faire avec

Plus de 100 outils de services Azure directement depuis votre client IA :

Interroger et gérer Cosmos DB, Storage, Key Vault, App Service, Foundry
Générer des commandes az CLI pour n’importe quelle tâche
Créer des modèles Bicep et Terraform

Pour commencer

Téléchargement : GitHub Releases
Dépôt : aka.ms/azmcp
Docs : aka.ms/azmcp/docs

Consultez le post complet.

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.

Foundry Toolboxes : Un seul endpoint pour tous les outils de vos agents

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

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

Voici un problème qui semble banal jusqu’à ce qu’on le vive : l’organisation construit plusieurs agents IA, chacun nécessite des outils, et chaque équipe les reconfigure à partir de zéro. La même intégration de recherche web, la même config Azure AI Search, la même connexion au serveur MCP GitHub — mais dans un autre dépôt, par une autre équipe, avec d’autres credentials et sans gouvernance partagée.

Microsoft Foundry vient de lancer Toolboxes en preview publique, et c’est une réponse directe à ce problème.

Qu’est-ce qu’une Toolbox ?

Une Toolbox est un bundle d’outils nommé et réutilisable, défini une fois dans Foundry et exposé via un unique endpoint compatible MCP. N’importe quel runtime d’agent qui parle MCP peut le consommer — pas d’enfermement dans Foundry Agents.

La promesse est simple : build once, consume anywhere. Définir les outils, configurer l’authentification de façon centralisée (OAuth passthrough, identité managée Entra), publier l’endpoint. Chaque agent qui a besoin de ces outils se connecte à l’endpoint et les obtient tous.

Les quatre piliers (deux disponibles aujourd’hui)

Pilier	Statut	Ce qu’il fait
Discover	Bientôt	Trouver des outils approuvés sans recherche manuelle
Build	Disponible	Regrouper des outils en un bundle réutilisable
Consume	Disponible	Un endpoint MCP unique expose tous les outils
Govern	Bientôt	Auth centralisée + observabilité pour tous les appels

Exemple pratique

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Chercher dans la documentation et répondre aux issues GitHub.",
 tools=[
 {"type": "web_search", "description": "Recherche dans la documentation publique"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Une fois publié, Foundry fournit un endpoint unifié. Une connexion, tous les outils.

Pas d’enfermement dans Foundry Agents

Les Toolboxes sont créées et gérées dans Foundry, mais la surface de consommation est le protocole MCP ouvert. On peut les utiliser depuis des agents personnalisés (Microsoft Agent Framework, LangGraph), GitHub Copilot et autres IDEs compatibles MCP, et tout runtime parlant MCP.

Pourquoi c’est important maintenant

La vague multi-agents arrive en production. Chaque nouvel agent est une nouvelle surface pour de la configuration dupliquée, des credentials obsolètes et des comportements incohérents. La base Build + Consume suffit pour commencer à centraliser. Quand le pilier Govern arrivera, on aura une couche d’outils entièrement observable et contrôlée centralement pour toute la flotte d’agents.

Conclusion

C’est encore tôt — preview publique, SDK Python en premier, Discover et Govern à venir. Mais le modèle est solide et le design natif MCP signifie qu’il fonctionne avec les outils qu’on construit déjà. Tous les détails dans l’annonce officielle.

Hooks azd en Python, TypeScript et .NET : fini les scripts shell

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

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

Vous avez déjà eu un projet entièrement en .NET et vous avez quand même dû écrire des scripts Bash pour les hooks azd ? Vous connaissez la douleur. Pourquoi basculer vers la syntaxe shell pour une étape de pré-provisioning quand tout le reste du projet est en C# ?

Cette frustration a maintenant une solution officielle. La CLI Azure Developer vient de publier la prise en charge multi-langages pour les hooks, et c’est exactement aussi bien que ça en a l’air.

Les hooks, en bref

Les hooks sont des scripts qui s’exécutent à des moments clés du cycle de vie d’azd — avant le provisioning, après le déploiement, etc. Définis dans azure.yaml, ils permettent d’injecter de la logique personnalisée sans modifier la CLI.

Avant, seuls Bash et PowerShell étaient supportés. Maintenant, on peut utiliser Python, JavaScript, TypeScript ou .NET — et azd s’occupe du reste automatiquement.

Comment fonctionne la détection

Il suffit de pointer le hook vers un fichier et azd déduit le langage à partir de l’extension :

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Pas de configuration supplémentaire. Si l’extension est ambiguë, on peut ajouter kind: python (ou le langage correspondant) pour le préciser.

Détails par langage

Python

Placer un requirements.txt ou pyproject.toml à côté du script (ou dans un répertoire parent). azd crée automatiquement un environnement virtuel, installe les dépendances et exécute le script.

JavaScript et TypeScript

Même principe — un package.json près du script, et azd exécute d’abord npm install. Pour TypeScript, il utilise npx tsx sans étape de compilation et sans tsconfig.json.

.NET

Deux modes disponibles :

Mode projet : Si un .csproj est présent à côté du script, azd exécute automatiquement dotnet restore et dotnet build.
Mode single-file : Sur .NET 10+, les fichiers .cs autonomes s’exécutent directement via dotnet run script.cs. Aucun fichier de projet requis.

Configuration par exécuteur

Chaque langage supporte un bloc config optionnel :

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Pourquoi c’est important pour les développeurs .NET

Les hooks étaient le dernier endroit dans un projet azd qui forçait à changer de langage. Maintenant, l’intégralité du pipeline de déploiement peut vivre dans un seul langage. Il devient possible de réutiliser les utilitaires .NET existants dans les hooks, de référencer des bibliothèques partagées et d’abandonner la maintenance de scripts shell.

Conclusion

Un de ces changements qui paraissent anodins mais qui réduisent concrètement la friction au quotidien avec azd. Le support multi-langages pour les hooks est disponible maintenant — tous les détails dans le post officiel.

Windows App Dev CLI v0.3 : F5 depuis le terminal et UI Automation pour les agents

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

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

L’expérience F5 de Visual Studio est formidable. Mais devoir ouvrir VS uniquement pour lancer et déboguer une application Windows packagée, c’est trop — que ce soit dans un pipeline CI, un workflow automatisé, ou quand un agent IA effectue les tests.

Windows App Development CLI v0.3 vient d’être publié et répond directement à ce besoin avec deux fonctionnalités phares : winapp run et winapp ui.

winapp run : F5 depuis n’importe où

winapp run prend un dossier d’application non packagée et un manifeste, et fait tout ce que VS fait au lancement debug : enregistre un package loose, lance l’application et préserve le LocalState entre les re-déploiements.

# Compiler l'app, puis la lancer comme app packagée
winapp run ./bin/Debug

Fonctionne pour WinUI, WPF, WinForms, Console, Avalonia et plus. Les modes sont conçus pour les développeurs et les workflows automatisés :

--detach : Lance et rend immédiatement le contrôle au terminal. Idéal pour CI/automation.
--unregister-on-exit : Nettoie le package enregistré à la fermeture de l’app.
--debug-output : Capture les messages OutputDebugString et les exceptions en temps réel.

Nouveau package NuGet : dotnet run pour les apps packagées

Pour les développeurs .NET, il y a un nouveau package NuGet : Microsoft.Windows.SDK.BuildTools.WinApp. Après installation, dotnet run gère tout l’inner loop : build, préparation du package loose-layout, enregistrement Windows et lancement — en une seule étape.

# Laisser winapp init tout configurer
winapp init
# Ou installer directement
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui : UI Automation depuis la ligne de commande

C’est la fonctionnalité qui ouvre les scénarios agentiques. winapp ui donne un accès UI Automation complet à toute application Windows en cours d’exécution — WPF, WinForms, Win32, Electron, WinUI3 — depuis le terminal.

Ce qu’on peut faire :

Lister toutes les fenêtres de niveau supérieur
Parcourir l’arborescence UI Automation complète d’une fenêtre
Rechercher des éléments par nom, type ou ID d’automatisation
Cliquer, invoquer et définir des valeurs
Prendre des captures d’écran
Attendre l’apparition d’éléments — idéal pour la synchronisation de tests

Combiner winapp ui avec winapp run donne un workflow complet build → lancement → vérification depuis le terminal. Un agent peut exécuter l’app, inspecter l’état de l’interface et valider le résultat.

Autres nouveautés

winapp unregister : Supprime un package sideloadé quand on a terminé.
winapp manifest add-alias : Ajoute un alias pour lancer l’app par nom depuis le terminal.
Complétion automatique : Un seul commande pour configurer la complétion PowerShell.

Installation

winget install Microsoft.WinAppCli
# ou
npm install -g @microsoft/winappcli

La CLI est en preview publique. Le dépôt GitHub contient la documentation complète et l’annonce originale tous les détails.

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

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.

Arrêtez de surveiller votre terminal : le mode détaché d'Aspire change la donne

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

À chaque fois que vous lancez un AppHost Aspire, votre terminal disparaît. Verrouillé. Occupé jusqu’à ce que vous fassiez Ctrl+C. Besoin d’exécuter une commande rapide ? Ouvrez un autre onglet. Envie de vérifier les logs ? Encore un onglet. C’est une petite friction qui s’accumule vite.

Aspire 13.2 corrige ça. James Newton-King a détaillé tout ça, et honnêtement, c’est une de ces fonctionnalités qui change immédiatement votre façon de travailler.

Mode détaché : une commande, terminal récupéré

aspire start

C’est le raccourci pour aspire run --detach. Votre AppHost démarre en arrière-plan et vous récupérez votre terminal immédiatement. Pas d’onglets supplémentaires. Pas de multiplexeur de terminal. Juste votre prompt, prêt à l’emploi.

Gérer ce qui tourne

Le truc, c’est que tourner en arrière-plan n’est utile que si on peut gérer ce qui s’y passe. Aspire 13.2 fournit un ensemble complet de commandes CLI pour exactement ça :

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Ça transforme le CLI d’Aspire en un véritable gestionnaire de processus. Vous pouvez démarrer plusieurs AppHosts, vérifier leur statut, suivre leurs logs et les arrêter — le tout depuis une seule session de terminal.

Combinez-le avec le mode isolé

Le mode détaché se marie naturellement avec le mode isolé. Vous voulez lancer deux instances du même projet en arrière-plan sans conflits de ports ?

aspire start --isolated
aspire start --isolated

Chacune obtient des ports aléatoires, des secrets séparés et son propre cycle de vie. Utilisez aspire ps pour voir les deux, aspire stop pour arrêter celle dont vous n’avez plus besoin.

Pourquoi c’est énorme pour les agents de code

C’est là que ça devient vraiment intéressant. Un agent de code travaillant dans votre terminal peut maintenant :

Démarrer l’app avec aspire start
Interroger son état avec aspire describe
Vérifier les logs avec aspire logs pour diagnostiquer les problèmes
L’arrêter avec aspire stop quand il a terminé

Tout ça sans perdre la session de terminal. Avant le mode détaché, un agent qui lançait votre AppHost se retrouvait bloqué dans son propre terminal. Maintenant il peut démarrer, observer, itérer et nettoyer — exactement comme on voudrait qu’un agent autonome fonctionne.

L’équipe Aspire a misé là-dessus. Lancer aspire agent init met en place un fichier de compétences Aspire qui enseigne ces commandes aux agents. Ainsi, des outils comme l’agent de code de Copilot peuvent gérer vos workloads Aspire directement.

Pour conclure

Le mode détaché est une amélioration du workflow déguisée en simple flag. Vous arrêtez de jongler entre les terminaux, les agents ne se bloquent plus eux-mêmes, et les nouvelles commandes CLI vous donnent une vraie visibilité sur ce qui tourne. C’est pratique, c’est propre, et ça rend le cycle de développement quotidien nettement plus fluide.

Lisez le post complet pour tous les détails et récupérez Aspire 13.2 avec aspire update --self.

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

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.

Les outils Azure MCP sont désormais intégrés dans Visual Studio 2022 — Aucune extension nécessaire

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

Si vous avez utilisé les outils Azure MCP dans Visual Studio via l’extension séparée, vous connaissez la chanson — installer le VSIX, redémarrer, espérer que rien ne casse, gérer les incompatibilités de versions. Cette friction, c’est terminé.

Yun Jung Choi a annoncé que les outils Azure MCP sont désormais livrés directement avec la charge de travail développement Azure dans Visual Studio 2022. Pas d’extension. Pas de VSIX. Pas de danse du redémarrage.

Ce que ça signifie concrètement

À partir de Visual Studio 2022 version 17.14.30, le Azure MCP Server est inclus dans la charge de travail développement Azure. Si vous avez déjà cette charge de travail installée, il suffit de l’activer dans GitHub Copilot Chat et c’est parti.

Plus de 230 outils couvrant 45 services Azure — accessibles directement depuis la fenêtre de chat. Listez vos comptes de stockage, déployez une app ASP.NET Core, diagnostiquez des problèmes App Service, interrogez Log Analytics — le tout sans ouvrir un onglet de navigateur.

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

Voici le truc avec l’outillage développeur : chaque étape supplémentaire est de la friction, et la friction tue l’adoption. Avoir MCP en tant qu’extension séparée signifiait des incompatibilités de versions, des échecs d’installation, et une chose de plus à maintenir à jour. L’intégrer dans la charge de travail signifie :

Un seul chemin de mise à jour via le Visual Studio Installer
Pas de décalage de version entre l’extension et l’IDE
Toujours à jour — le MCP Server se met à jour avec les releases régulières de VS

Pour les équipes qui standardisent sur Azure, c’est un vrai gain. Vous installez la charge de travail une fois, activez les outils, et ils sont disponibles à chaque session.

Ce que vous pouvez faire avec

Les outils couvrent l’intégralité du cycle de développement via Copilot Chat :

Apprendre — posez des questions sur les services Azure, les bonnes pratiques, les patterns d’architecture
Concevoir et développer — obtenez des recommandations de services, configurez le code de votre application
Déployer — provisionnez des ressources et déployez directement depuis l’IDE
Dépanner — interrogez les logs, vérifiez l’état des ressources, diagnostiquez les problèmes en production

Un exemple rapide — tapez ceci dans Copilot Chat :

List my storage accounts in my current subscription.

Copilot appelle les outils Azure MCP en coulisses, interroge vos abonnements, et renvoie une liste formatée avec les noms, emplacements et SKUs. Pas besoin du portail.

Comment l’activer

Mettez à jour vers Visual Studio 2022 17.14.30 ou supérieur
Assurez-vous que la charge de travail Azure development est installée
Ouvrez GitHub Copilot Chat
Cliquez sur le bouton Select tools (l’icône des deux clés)
Activez Azure MCP Server

C’est tout. Ça reste activé entre les sessions.

Un bémol

Les outils sont désactivés par défaut — vous devez les activer manuellement. Et les outils spécifiques à VS 2026 ne sont pas disponibles dans VS 2022. La disponibilité des outils dépend également des permissions de votre abonnement Azure, comme sur le portail.

La vue d’ensemble

Cela fait partie d’une tendance claire : MCP est en train de devenir le standard pour exposer les outils cloud dans les IDEs de développement. Nous avons déjà vu la release stable d’Azure MCP Server 2.0 et des intégrations MCP dans VS Code et d’autres éditeurs. L’intégrer dans le système de charges de travail de Visual Studio est la progression naturelle.

Pour nous développeurs .NET qui vivons dans Visual Studio, ça élimine encore une raison de basculer vers le portail Azure. Et honnêtement, moins on change d’onglet, mieux c’est.

azd update — Une seule commande pour tous vos gestionnaires de paquets

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Vous connaissez ce message « Une nouvelle version de azd est disponible » qui apparaît toutes les quelques semaines ? Celui que vous ignorez parce que vous ne vous souvenez plus si vous avez installé azd via winget, Homebrew ou ce script curl que vous avez exécuté il y a six mois ? Eh bien, c’est enfin réglé.

Microsoft vient de publier azd update — une seule commande qui met à jour Azure Developer CLI vers la dernière version, quelle que soit la méthode d’installation d’origine. Windows, macOS, Linux — peu importe. Une seule commande.

Comment ça marche

azd update

C’est tout. Si vous voulez un accès anticipé aux nouvelles fonctionnalités, vous pouvez passer au build insiders quotidien :

azd update --channel daily
azd update --channel stable

La commande détecte votre méthode d’installation actuelle et utilise le mécanisme de mise à jour approprié en arrière-plan. Fini le « attends, j’ai utilisé winget ou choco sur cette machine ? »

Le petit bémol

azd update est disponible à partir de la version 1.23.x. Si vous êtes sur une version antérieure, vous devrez effectuer une dernière mise à jour manuelle en utilisant votre méthode d’installation d’origine. Après ça, azd update gère tout automatiquement.

Vérifiez votre version actuelle avec azd version. Si vous avez besoin d’une nouvelle installation, la documentation d’installation est là pour vous.

Pourquoi c’est important

C’est une petite amélioration de confort, mais pour ceux d’entre nous qui utilisent azd quotidiennement pour déployer des agents IA et des apps Aspire sur Azure, être à jour signifie moins de moments « ce bug était déjà corrigé dans la dernière version ». Une chose de moins à laquelle penser.

Lisez l’annonce complète et l’analyse approfondie de Jon Gallant pour plus de contexte.

.NET Aspire 13.2 Veut Devenir le Meilleur Ami de Votre Agent IA

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

Tu connais ce moment où ton agent IA écrit du code solide, tu es tout excité, et puis tout s’effondre quand il essaie de lancer le truc ? Conflits de ports, processus fantômes, mauvaises variables d’environnement — soudain ton agent brûle des tokens à déboguer des problèmes de démarrage au lieu de construire des fonctionnalités.

L’équipe Aspire vient de publier un post très bien pensé sur exactement ce problème, et leur réponse est convaincante : Aspire 13.2 est conçu non seulement pour les humains, mais pour les agents IA.

Le problème est réel

Les agents IA sont incroyables pour écrire du code. Mais livrer une app full-stack fonctionnelle implique bien plus que générer des fichiers. Il faut démarrer les services dans le bon ordre, gérer les ports, configurer les variables d’environnement, connecter les bases de données et obtenir du feedback quand ça casse. Actuellement, la plupart des agents gèrent tout ça par essai-erreur — exécuter des commandes, lire les sorties d’erreur, réessayer.

On empile des instructions Markdown, des skills personnalisés et des prompts pour les guider, mais c’est imprévisible, ça ne se compile pas, et ça coûte des tokens juste pour parser. L’équipe Aspire a mis le doigt sur l’insight clé : les agents ont besoin de compilateurs et d’APIs structurées, pas de plus de Markdown.

Aspire comme infrastructure pour agents

Voici ce qu’Aspire 13.2 apporte à la table du développement agentique :

Toute ta stack en code typé. L’AppHost définit ta topologie complète — API, frontend, base de données, cache — en TypeScript ou C# compilable :

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Un agent peut lire ça pour comprendre la topologie de l’app, ajouter des ressources, câbler les connexions et compiler pour vérifier. Le compilateur lui dit immédiatement si quelque chose ne va pas. Pas de devinettes, pas d’essai-erreur avec les fichiers de config.

Une seule commande pour les gouverner toutes. Au lieu que les agents jonglent entre docker compose up, npm run dev et les scripts de démarrage de base de données, tout est simplement aspire start. Toutes les ressources se lancent dans le bon ordre, sur les bons ports, avec la bonne configuration. Les processus longs ne bloquent pas non plus l’agent — Aspire les gère.

Mode isolé pour les agents parallèles. Avec --isolated, chaque exécution d’Aspire obtient ses propres ports aléatoires et secrets utilisateur séparés. Plusieurs agents travaillent sur des git worktrees ? Ils n’entreront pas en collision. C’est énorme pour des outils comme les agents en arrière-plan de VS Code qui créent des environnements parallèles.

Des yeux d’agent grâce à la télémétrie. C’est là que ça devient vraiment puissant. La CLI Aspire expose des données OpenTelemetry complètes pendant le développement — traces, métriques, logs structurés. Ton agent ne se contente pas de lire la sortie console en espérant que tout va bien. Il peut tracer une requête échouée à travers les services, profiler les endpoints lents et identifier précisément où les choses cassent. C’est de l’observabilité de niveau production dans la boucle de développement.

L’analogie des bumpers de bowling

L’équipe Aspire utilise une super analogie : pense à Aspire comme les bumpers de piste de bowling pour les agents IA. Si l’agent n’est pas parfait (et il ne le sera pas), les bumpers l’empêchent de faire des gouttières. La définition de la stack empêche les mauvaises configurations, le compilateur attrape les erreurs, la CLI gère les processus, et la télémétrie fournit la boucle de feedback.

Combine ça avec quelque chose comme Playwright CLI, et ton agent peut réellement utiliser ton app — cliquer dans les flux, vérifier le DOM, voir les trucs cassés dans la télémétrie, corriger le code, redémarrer et retester. Construire, exécuter, observer, corriger. C’est la boucle de développement autonome que nous poursuivons.

Pour démarrer

Nouveau avec Aspire ? Installe la CLI depuis get.aspire.dev et suis le guide de démarrage.

Tu utilises déjà Aspire ? Lance aspire update --self pour obtenir la 13.2, puis pointe ton agent de coding favori vers ton repo. Tu seras surpris de voir jusqu’où il ira avec les garde-fous d’Aspire.

Pour conclure

Aspire 13.2 n’est plus seulement un framework d’applications distribuées — il devient une infrastructure essentielle pour les agents. Des définitions de stack structurées, un démarrage en une commande, des exécutions parallèles isolées et de la télémétrie en temps réel donnent aux agents IA exactement ce dont ils ont besoin pour passer de l’écriture de code à la livraison d’apps.

Lis le post complet de l’équipe Aspire pour tous les détails et vidéos de démo.

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

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.

Le Mode Isolé d'Aspire Résout le Cauchemar des Conflits de Ports pour le Développement Parallèle

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

Si tu as déjà essayé d’exécuter deux instances du même projet en même temps, tu connais la douleur. Le port 8080 est déjà utilisé. Le port 17370 est pris. Tuer quelque chose, redémarrer, jongler avec les variables d’environnement — c’est un tueur de productivité.

Ce problème empire, il ne s’améliore pas. Les agents IA créent des git worktrees pour travailler indépendamment. Les agents en arrière-plan démarrent des environnements séparés. Les développeurs font des checkout du même repo deux fois pour des branches de fonctionnalités. Chacun de ces scénarios frappe le même mur : deux instances de la même app qui se battent pour les mêmes ports.

Aspire 13.2 résout ça avec un seul flag. James Newton-King de l’équipe Aspire a écrit tous les détails, et c’est une de ces fonctionnalités « pourquoi on n’avait pas ça avant ? ».

La solution : `--isolated`

aspire run --isolated

C’est tout. Chaque exécution obtient :

Des ports aléatoires — plus de collisions entre instances
Des secrets utilisateur isolés — les chaînes de connexion et clés API restent séparées par instance

Pas de réattribution manuelle de ports. Pas de jonglage avec les variables d’environnement. Chaque exécution obtient un environnement propre et sans collision automatiquement.

Scénarios réels où ça brille

Checkouts multiples. Tu as une branche de fonctionnalité dans un répertoire et un bugfix dans un autre :

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Les deux tournent sans conflit. Le dashboard montre ce qui tourne et où.

Agents en arrière-plan dans VS Code. Quand l’agent en arrière-plan de Copilot Chat crée un git worktree pour travailler sur ton code indépendamment, il peut avoir besoin d’exécuter ton AppHost Aspire. Sans --isolated, c’est un conflit de ports avec ton worktree principal. Avec, les deux instances fonctionnent tout simplement.

Le skill Aspire livré avec aspire agent init instruit automatiquement les agents d’utiliser --isolated quand ils travaillent dans des worktrees. Donc l’agent en arrière-plan de Copilot devrait gérer ça nativement.

Tests d’intégration en parallèle du développement. Besoin d’exécuter des tests contre un AppHost live tout en continuant à développer des fonctionnalités ? Le mode isolé donne à chaque contexte ses propres ports et sa propre config.

Comment ça fonctionne sous le capot

Quand tu passes --isolated, la CLI génère un ID d’instance unique pour l’exécution. Cela pilote deux comportements :

Randomisation des ports — au lieu de se lier à des ports prévisibles définis dans la config de ton AppHost, le mode isolé choisit des ports aléatoires disponibles pour tout — le dashboard, les endpoints de services, tout. Le service discovery s’ajuste automatiquement, pour que les services se trouvent mutuellement quel que soit le port attribué.
Isolation des secrets — chaque exécution isolée obtient son propre store de secrets utilisateur, indexé par l’ID d’instance. Les chaînes de connexion et clés API d’une exécution ne fuient pas dans une autre.

Ton code n’a besoin d’aucun changement. Le service discovery d’Aspire résout les endpoints au runtime, donc tout se connecte correctement quelle que soit l’attribution des ports.

Quand l’utiliser

Utilise --isolated quand tu exécutes plusieurs instances du même AppHost simultanément — que ce soit pour du développement parallèle, des tests automatisés, des agents IA ou des git worktrees. Pour du développement mono-instance où tu préfères des ports prévisibles, le aspire run classique fonctionne toujours très bien.

Pour conclure

Le mode isolé est une petite fonctionnalité qui résout un problème réel et de plus en plus courant. Alors que le développement assisté par IA nous pousse vers plus de workflows parallèles — agents multiples, worktrees multiples, contextes multiples — la capacité de simplement lancer une autre instance sans se battre pour les ports est essentielle.

Lis le post complet pour tous les détails techniques et essaie-le avec aspire update --self pour obtenir la 13.2.

VS Code 1.116 — L'App Agents Obtient la Navigation Clavier et les Complétions de Contexte de Fichiers

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

VS Code 1.116 est la version d’avril 2026, et bien qu’elle soit plus légère que certaines mises à jour récentes, les changements sont ciblés et significatifs — surtout si vous utilisez l’app Agents au quotidien.

Voici ce qui a atterri, d’après les notes de version officielles.

Améliorations de l’app Agents

L’app Agents continue de mûrir avec un polissage de l’ergonomie qui fait une vraie différence dans les flux de travail quotidiens :

Raccourcis clavier dédiés — vous pouvez maintenant cibler la vue Changes, l’arborescence de fichiers dans Changes, et la vue des Personnalisations du Chat avec des commandes et raccourcis clavier dédiés. Si vous cliquiez partout dans l’app Agents pour naviguer, cela apporte des flux de travail entièrement pilotés au clavier.

Dialogue d’aide à l’accessibilité — appuyer sur Alt+F1 dans la zone de saisie du chat ouvre maintenant un dialogue d’aide à l’accessibilité montrant les commandes et raccourcis disponibles. Les utilisateurs de lecteurs d’écran peuvent aussi contrôler la verbosité des annonces. Une bonne accessibilité profite à tout le monde.

Complétions de contexte de fichiers — tapez # dans le chat de l’app Agents pour déclencher les complétions de contexte de fichiers limitées à votre espace de travail actuel. C’est une de ces petites améliorations de qualité de vie qui accélèrent chaque interaction — plus besoin de taper des chemins de fichiers complets en référençant du code.

Résolution des liens CSS `@import`

Agréable pour les développeurs frontend : VS Code résout maintenant les références CSS @import qui utilisent des chemins node_modules. Vous pouvez faire Ctrl+clic à travers des imports comme @import "some-module/style.css" en utilisant des bundlers. Petit mais élimine un point de friction dans les workflows CSS.

Conclusion

VS Code 1.116 est une affaire de raffinement — rendre l’app Agents plus navigable, plus accessible et plus conviviale au clavier. Si vous passez beaucoup de temps dans l’app Agents (et je soupçonne que beaucoup d’entre nous le font), ces changements s’accumulent.

Consultez les notes de version complètes pour la liste exhaustive.

VS Code 1.115 — Notifications de Terminal en Arrière-plan, Mode Agent SSH et Plus

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

VS Code 1.115 vient de sortir, et bien que ce soit une version plus légère en termes de fonctionnalités phares, les améliorations liées aux agents sont vraiment utiles si vous travaillez quotidiennement avec des assistants de code IA.

Permettez-moi de souligner ce qui vaut vraiment la peine d’être connu.

Les terminaux en arrière-plan communiquent avec les agents

C’est la fonctionnalité vedette. Les terminaux en arrière-plan notifient désormais automatiquement les agents lorsque les commandes se terminent, y compris le code de sortie et la sortie du terminal. Les invites de saisie dans les terminaux en arrière-plan sont également détectées et présentées à l’utilisateur.

Pourquoi est-ce important ? Si vous avez utilisé le mode agent de Copilot pour exécuter des commandes de build ou des suites de tests en arrière-plan, vous connaissez la frustration du “est-ce que c’est fini ?” — les terminaux en arrière-plan étaient essentiellement du fire-and-forget. Maintenant l’agent est notifié quand votre dotnet build ou dotnet test se termine, voit la sortie et peut réagir en conséquence. C’est un petit changement qui rend les workflows pilotés par les agents nettement plus fiables.

Il y a aussi un nouvel outil send_to_terminal qui permet aux agents d’envoyer des commandes aux terminaux en arrière-plan avec confirmation de l’utilisateur, corrigeant le problème où run_in_terminal avec un timeout déplaçait les terminaux en arrière-plan et les rendait en lecture seule.

Hébergement d’agents distants via SSH

VS Code prend désormais en charge la connexion à des machines distantes via SSH, en installant automatiquement le CLI et en le démarrant en mode hôte d’agents. Cela signifie que vos sessions d’agents IA peuvent cibler directement des environnements distants — utile pour les développeurs .NET qui compilent et testent sur des serveurs Linux ou des VMs cloud.

Suivi des modifications dans les sessions d’agents

Les modifications de fichiers effectuées pendant les sessions d’agents sont désormais suivies et restaurées, avec des diffs, annuler/rétablir et restauration d’état. Si un agent modifie votre code et que quelque chose tourne mal, vous pouvez voir exactement ce qui a changé et le reverter. La tranquillité d’esprit pour laisser les agents modifier votre codebase.

Reconnaissance des onglets du navigateur et autres améliorations

Quelques ajouts supplémentaires de qualité de vie :

Suivi des onglets du navigateur — le chat peut désormais suivre et lier les onglets du navigateur ouverts pendant une session, pour que les agents puissent référencer les pages web que vous consultez
Collage de fichiers dans le terminal — collez des fichiers (y compris des images) dans le terminal avec Ctrl+V, glisser-déposer ou clic droit
Couverture de tests dans la minimap — les indicateurs de couverture de tests s’affichent désormais dans la minimap pour un aperçu visuel rapide
Pinch-to-zoom sur Mac — le navigateur intégré prend en charge les gestes de pinch-to-zoom
Droits Copilot dans les Sessions — la barre d’état affiche les informations d’utilisation dans la vue Sessions
Favicon dans Aller au Fichier — les pages web ouvertes affichent des favicons dans la liste de sélection rapide

Pour conclure

VS Code 1.115 est une version incrémentale, mais les améliorations des agents — notifications de terminal en arrière-plan, hébergement d’agents SSH et suivi des modifications — contribuent à une expérience nettement plus fluide pour le développement assisté par IA. Si vous utilisez le mode agent de Copilot pour des projets .NET, ce sont le genre d’améliorations de qualité de vie qui réduisent les frictions au quotidien.

Consultez les notes de version complètes pour tous les détails.

Aspire 13.2 embarque une CLI de documentation — et votre agent IA peut l'utiliser aussi

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

Vous connaissez ce moment où vous êtes plongé dans un Aspire AppHost, en train de câbler des intégrations, et vous devez vérifier exactement quels paramètres l’intégration Redis attend ? Vous faites alt-tab vers votre navigateur, vous cherchez sur aspire.dev, vous plissez les yeux sur les docs de l’API, puis vous revenez à votre éditeur. Contexte perdu. Flow brisé.

Aspire 13.2 vient de livrer une solution à ça. La CLI aspire docs vous permet de rechercher, parcourir et lire la documentation officielle d’Aspire directement depuis votre terminal. Et comme elle s’appuie sur des services réutilisables, les agents IA et les skills peuvent utiliser les mêmes commandes pour consulter la doc au lieu d’halluciner des APIs qui n’existent pas.

Le problème que ça résout vraiment

David Pine le dit parfaitement dans le post original : les agents IA étaient catastrophiques pour aider les développeurs à construire des apps Aspire. Ils recommandaient dotnet run au lieu de aspire run, référençaient learn.microsoft.com pour des docs qui se trouvent sur aspire.dev, suggéraient des packages NuGet obsolètes, et — mon préféré — hallucinaient des APIs inexistantes.

Pourquoi ? Parce qu’Aspire a été spécifique à .NET bien plus longtemps qu’il n’est polyglotte, et les LLMs travaillent avec des données d’entraînement qui précèdent les dernières fonctionnalités. Quand vous donnez à un agent IA la capacité de consulter les docs actuels, il arrête de deviner et commence à être utile.

Trois commandes, zéro onglet de navigateur

La CLI est d’une simplicité rafraîchissante :

Lister toute la documentation

aspire docs list

Retourne chaque page de documentation disponible sur aspire.dev. Besoin d’une sortie lisible par une machine ? Ajoutez --format Json.

Rechercher un sujet

aspire docs search "redis"

Recherche à la fois dans les titres et le contenu avec un score de pertinence pondéré. Le même moteur de recherche qui alimente les outils de documentation en interne. Vous obtenez des résultats classés avec titres, slugs et scores de pertinence.

Lire une page complète (ou juste une section)

aspire docs get redis-integration

Envoie la page complète en markdown dans votre terminal. Besoin d’une seule section ?

aspire docs get redis-integration --section "Add Redis resource"

Précision chirurgicale. Pas besoin de scroller 500 lignes. Juste la partie dont vous avez besoin.

L’angle agent IA

C’est là que ça devient intéressant pour nous, développeurs qui construisons avec des outils IA. Les mêmes commandes aspire docs fonctionnent comme outils pour les agents IA — via des skills, des serveurs MCP, ou de simples wrappers CLI.

Au lieu que votre assistant IA invente des APIs Aspire basées sur des données d’entraînement obsolètes, il peut appeler aspire docs search "postgres", trouver les docs d’intégration officiels, lire la bonne page, et vous donner l’approche documentée. De la documentation en temps réel et à jour — pas ce que le modèle a mémorisé il y a six mois.

L’architecture derrière tout ça est intentionnelle. L’équipe Aspire a construit des services réutilisables (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) plutôt qu’une intégration ponctuelle. Cela signifie que le même moteur de recherche fonctionne pour les humains dans le terminal, les agents IA dans votre éditeur, et l’automatisation dans votre pipeline CI.

Scénarios concrets

Consultations rapides dans le terminal : Vous êtes trois fichiers en profondeur et vous avez besoin des paramètres de configuration Redis. Deux commandes, quatre-vingt-dix secondes, retour au travail :

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Développement assisté par IA : Votre skill VS Code encapsule les commandes CLI. Vous demandez « Ajoute une base de données PostgreSQL à mon AppHost » et l’agent consulte les vrais docs avant de répondre. Pas d’hallucinations.

Validation CI/CD : Votre pipeline valide les configurations AppHost contre la documentation officielle de manière programmatique. La sortie --format Json se connecte proprement à jq et d’autres outils.

Bases de connaissances personnalisées : Vous construisez vos propres outils IA ? Envoyez la sortie JSON structurée directement dans votre base de connaissances :

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Pas de web scraping. Pas de clés API. Les mêmes données structurées utilisées en interne par les outils de documentation.

La documentation est toujours à jour

C’est la partie que j’apprécie le plus. La CLI ne télécharge pas un snapshot — elle interroge aspire.dev avec un cache basé sur les ETags. Dès que la documentation est mise à jour, votre CLI et tout skill construit dessus le reflète. Pas de copies obsolètes, pas de moments « mais le wiki disait… ».

Pour conclure

aspire docs est une de ces petites fonctionnalités qui résout un vrai problème proprement. Les humains obtiennent un accès à la documentation natif au terminal. Les agents IA obtiennent un moyen d’arrêter de deviner et de commencer à référencer de vrais docs. Et tout est soutenu par la même source de vérité.

Si vous construisez avec .NET Aspire et n’avez pas encore essayé la CLI, lancez aspire docs search "votre-sujet-ici" et voyez comment ça se passe. Ensuite, envisagez d’intégrer ces commandes dans votre skill IA ou votre configuration d’automatisation — vos agents vous remercieront.

Consultez l’analyse approfondie de David Pine sur la construction des outils de documentation, et la référence officielle de la CLI pour tous les détails.

azd permet maintenant d'exécuter et déboguer des agents IA localement — Ce qui a changé en mars 2026

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

Sept versions en un mois. C’est ce que l’équipe Azure Developer CLI (azd) a livré en mars 2026, et la fonctionnalité phare est celle que j’attendais : une boucle locale d’exécution et débogage pour les agents IA.

PC Chan a publié le récapitulatif complet, et bien qu’il y ait beaucoup de contenu, laissez-moi filtrer ce qui compte vraiment pour les développeurs .NET qui construisent des apps alimentées par l’IA.

Exécuter et déboguer des agents IA sans déployer

C’est le gros morceau. La nouvelle extension azure.ai.agents ajoute des commandes qui offrent une vraie boucle interne pour les agents IA :

azd ai agent run — démarre votre agent localement
azd ai agent invoke — lui envoie des messages (local ou déployé)
azd ai agent show — affiche le statut du conteneur et sa santé
azd ai agent monitor — diffuse les logs du conteneur en temps réel

Avant, tester un agent IA signifiait déployer sur Microsoft Foundry à chaque modification. Maintenant, vous pouvez itérer localement, tester le comportement de votre agent, et ne déployer que quand vous êtes prêt.

GitHub Copilot configure votre projet azd

azd init offre maintenant une option “Set up with GitHub Copilot (Preview)”. Au lieu de répondre manuellement aux prompts, un agent Copilot génère la configuration pour vous. Quand une commande échoue, azd propose un dépannage assisté par IA — tout sans quitter le terminal.

Container App Jobs et améliorations de déploiement

Container App Jobs : azd déploie maintenant Microsoft.App/jobs via la config existante host: containerapp.
Timeouts configurables : Nouveau flag --timeout sur azd deploy et champ deployTimeout dans azure.yaml.
Fallback de build distant : En cas d’échec du build ACR, azd retombe automatiquement sur Docker/Podman local.
Validation preflight locale : Les paramètres Bicep sont validés localement avant le déploiement.

Améliorations DX

Détection automatique pnpm/yarn pour les projets JS/TS
Support pyproject.toml pour le packaging Python
Répertoires de templates locaux — azd init --template accepte les chemins du système de fichiers
Meilleurs messages d’erreur en mode --no-prompt
Variables d’environnement de build injectées dans tous les sous-processus de build (.NET, Node.js, Java, Python)

Pour conclure

La boucle locale de débogage d’agents IA est la star de cette version, mais l’accumulation d’améliorations de déploiement et de polish DX rend azd plus mature que jamais. Si vous déployez des apps .NET sur Azure — surtout des agents IA — cette mise à jour vaut le détour.

Consultez les notes de version complètes pour tous les détails.

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

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

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

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.

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

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.

Du laptop à la production : déployer des agents IA sur Microsoft Foundry en deux commandes

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

Vous connaissez ce fossé entre “ça marche sur ma machine” et “c’est déployé et sert du trafic” ? Pour les agents IA, ce fossé a été douloureusement large. Il faut provisionner des ressources, déployer des modèles, configurer l’identité, mettre en place le monitoring — et tout ça avant que quiconque puisse réellement appeler votre agent.

L’Azure Developer CLI vient d’en faire une affaire de deux commandes.

Le nouveau workflow `azd ai agent`

Laissez-moi vous montrer ce que ça donne concrètement. Vous avez un projet d’agent IA — disons un agent concierge d’hôtel. Il fonctionne en local. Vous voulez qu’il tourne sur Microsoft Foundry.

azd ai agent init
azd up

C’est tout. Deux commandes. azd ai agent init génère l’infrastructure-as-code dans votre repo, et azd up provisionne tout sur Azure et publie votre agent. Vous obtenez un lien direct vers votre agent dans le portail Foundry.

Ce qui se passe sous le capot

La commande init génère de vrais templates Bicep inspectables dans votre repo :

Une Foundry Resource (conteneur de niveau supérieur)
Un Foundry Project (où vit votre agent)
Configuration du déploiement de modèle (GPT-4o, etc.)
Identité managée avec les attributions de rôles RBAC appropriées
azure.yaml pour la carte des services
agent.yaml avec les métadonnées de l’agent et les variables d’environnement

Le point clé : tout cela vous appartient. C’est du Bicep versionné dans votre repo. Vous pouvez l’inspecter, le personnaliser et le commiter aux côtés du code de votre agent. Pas de boîtes noires magiques.

La boucle interne de développement

Ce que j’aime vraiment, c’est l’expérience de développement local. Quand vous itérez sur la logique de l’agent, vous ne voulez pas redéployer à chaque modification d’un prompt :

azd ai agent run

Cela démarre votre agent localement. Combinez-le avec azd ai agent invoke pour envoyer des prompts de test, et vous avez une boucle de feedback rapide. Modifier le code, redémarrer, invoquer, répéter.

La commande invoke est intelligente pour le routage aussi — quand un agent local tourne, elle le cible automatiquement. Sinon, elle va vers l’endpoint distant.

Monitoring en temps réel

C’est la fonctionnalité qui m’a convaincu. Une fois votre agent déployé :

azd ai agent monitor --follow

Chaque requête et réponse transitant par votre agent est streamée vers votre terminal en temps réel. Pour déboguer des problèmes en production, c’est inestimable. Plus besoin de fouiller dans les Log Analytics, plus d’attente pour l’agrégation des métriques — vous voyez ce qui se passe maintenant.

L’ensemble complet des commandes

Voici la référence rapide :

Commande	Ce qu’elle fait
`azd ai agent init`	Scaffold d’un projet agent Foundry avec IaC
`azd up`	Provisionne les ressources Azure et déploie l’agent
`azd ai agent invoke`	Envoie des prompts à l’agent distant ou local
`azd ai agent run`	Exécute l’agent localement pour le développement
`azd ai agent monitor`	Streame les logs en temps réel de l’agent publié
`azd ai agent show`	Vérifie la santé et le statut de l’agent
`azd down`	Nettoie toutes les ressources Azure

Pourquoi c’est important pour les développeurs .NET

Même si l’exemple de l’annonce est basé sur Python, l’histoire de l’infrastructure est agnostique au langage. Votre agent .NET bénéficie du même scaffolding Bicep, de la même configuration d’identité managée, du même pipeline de monitoring. Et si vous utilisez déjà azd pour vos apps .NET Aspire ou vos déploiements Azure, ça s’intègre directement dans votre workflow existant.

Le fossé de déploiement pour les agents IA a été l’un des plus grands points de friction dans l’écosystème. Passer d’un prototype fonctionnel à un endpoint de production avec identité, réseau et monitoring appropriés ne devrait pas nécessiter une semaine de travail DevOps. Maintenant il faut deux commandes et quelques minutes.

Pour conclure

azd ai agent est disponible maintenant. Si vous avez repoussé le déploiement de vos agents IA parce que la mise en place de l’infrastructure semblait trop de travail, essayez. Consultez le walkthrough complet pour le guide étape par étape incluant l’intégration d’une app de chat frontend.