The .NET Blog

NDC Oslo 2026

Mon, 14 Sep 2026 00:00:00 +0000

NDC Oslo 2026 se déroule du 14 au 18 septembre 2026 à Oslo Spektrum, Oslo, Norvège.

NDC Oslo est l’une des plus grandes et des plus respectées conférences développeurs en Europe, couvrant tout, de .NET et le cloud à la sécurité, l’architecture, l’IA et au-delà. L’édition 2026 est actuellement en phase de réservation, avec un programme massif en préparation.

En chiffres

160 sessions (en cours de réservation)
150 speakers (en cours de réservation)
15 workshops (en cours de réservation)
5 jours — workshops + conférence

Speakers confirmés

La liste des speakers se construit, avec des noms confirmés incluant :

Nick Chapsas
Maddy Montaquila
Troy Hunt
Kevlin Henney
Venkat Subramaniam
Jeff Fritz
Philippe De Ryck
Nhlanhla Lucky Nkosi
Aleksander Stensby

Billets

Les billets Early Bird sont disponibles — l’offre Early Bird se termine le 22 mai 2026.

Le CFP (Call for Papers) est également ouvert.

Autres événements NDC en 2026

NDC Sydney — 22–24 avril 2026
NDC Toronto — 5–8 mai 2026
NDC Copenhagen — 1–4 juin 2026
NDC AI — 8–10 juin 2026
NDC TechTown — 21–24 septembre 2026

Liens

.NET Day Switzerland 2026

Tue, 25 Aug 2026 00:00:00 +0000

.NET Day Switzerland 2026 se tient le 25 août 2026 au Arena Cinemas Sihlcity (Kalanderplatz 8, 8045 Zurich).

C’est une conférence communautaire indépendante et à but non lucratif pour les développeurs, architectes et experts qui souhaitent échanger sur .NET, C#, ASP.NET Core, Azure et l’écosystème de développement Microsoft. Tous les speakers et bénévoles donnent de leur temps, et tout excédent des ventes de billets est reversé à des œuvres caritatives ou à la communauté .NET suisse.

Ce qui vous attend

Sessions de haute qualité avec des experts internationaux
Networking avec d’autres participants
Repas, snacks et boissons pendant les pauses, le déjeuner et l’apéro
Opportunités de carrière grâce aux interactions avec les sponsors
Discussions directes avec les speakers pendant les pauses

Billets

Catégorie	Prix	Disponibilité
Very Early Bird (1–30 avr)	299 CHF	Max. 100 billets
Early Bird	399 CHF	Max. 100 billets
Regular	449 CHF	Jusqu’à épuisement

Les speakers et le programme n’ont pas encore été annoncés — l’appel à speakers est ouvert sur Sessionize.

Organisateurs

Liens

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 se déroule du 11 au 15 mai 2026 au Barbican Centre à Londres. La conférence principale de 3 jours va du mardi au jeudi, avec des workshops optionnels d’une journée le lundi et le vendredi.

Avec 78 sessions et 14 workshops, c’est l’une des conférences développeurs les plus denses en Europe.

Sujets

Pensée Architecturale
Code Fonctionnel en C# 13
Design Serverless
IA Sémantique
Azure Kubernetes Services
Stratégies Lean DevOps
The Model Context Protocol (MCP)
IA Agentique en .NET
Refactoring du Monolithe
Coder Plus Vite avec les LLMs
Cryptographie dans un Monde Post-Quantique
Développement Local First

Speakers

Un plateau de classe mondiale avec Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm et Raju Gandhi.

Billets et informations

98 % des participants de SDD 2025 ont évalué l’expérience globale comme bonne, très bonne ou excellente.

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

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

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

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

Support des Requêtes WIQL

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

Personal Access Tokens

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

Annotations MCP

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

Consolidation des Outils Wiki

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

Expérimental : MCP Apps

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

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

SQL Server 2025 comme Base de Données Prête pour les Agents : Sécurité, Backup et MCP dans un Seul Moteur

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

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

J’ai suivi la série Polyglot Tax d’Aditya Badramraju avec beaucoup d’intérêt. La partie 4 clôt la série avec les parties qui déterminent vraiment si vous feriez confiance à cette architecture en production.

Un Modèle de Sécurité pour Tous les Modèles de Données

Une seule politique Row-Level Security couvre toutes les tables — relationnelles, JSON, graphes, vecteurs. Une politique, une preuve pour l’auditeur.

Backup Unifié = Récupération Atomique

Dans un stack polyglottes, la récupération point-in-time sur cinq bases de données est un cauchemar de cohérence. Avec une seule base de données, c’est atomique par définition.

Intégration MCP : Agents Sans Middleware

SQL Server 2025 supporte directement le SQL MCP Server. Les agents appellent des outils, le moteur impose l’isolation tenant et le masquage des colonnes automatiquement.

Conclusion

Pour les développeurs .NET qui construisent des applications agent-first sur Azure SQL, cette architecture mérite une sérieuse considération. Post original d’Aditya Badramraju : The Polyglot Tax – Part 4.

.NET 10 Est Livré avec Ubuntu 26.04 LTS — Ce qui Est Nouveau

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

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

C’est le jour de l’Ubuntu LTS. Ubuntu 26.04 (Resolute Raccoon) est sorti aujourd’hui avec .NET 10.

LTS sur LTS — cinq ans de support pour l’OS, correspondant à la fenêtre de support long terme de .NET 10.

Installer .NET 10 en deux commandes

sudo apt update
sudo apt install dotnet-sdk-10.0

.NET est l’une des toolchains officiellement supportées sur Ubuntu — pas un add-on tiers.

Conteneurs : mettre à jour `-noble` vers `-resolute`

La migration est une seule ligne :

sed -i "s/noble/resolute/g" Dockerfile

Toutes les variantes d’images existantes — y compris Chiseled — sont disponibles.

Native AOT : démarrage en 3ms, binaire de 1,4MB

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# artifacts/app/app — binaire natif de 1,4MB
# real 0m0.003s

Pour les charges de travail cloud-native où le temps de démarrage à froid compte — Functions, conteneurs, serverless — c’est un vrai changement de jeu.

Besoin de .NET 8 ou 9 ?

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

Le post complet contient plus de détails.

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.

Azure SDK Avril 2026 : AI Foundry 2.0 et Ce Que les Développeurs .NET Doivent Savoir

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

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

Les versions mensuelles du SDK sont souvent faciles à ignorer. Celle-ci a quelques points à retenir — surtout si vous construisez avec AI Foundry, Cosmos DB en Java, ou faites du provisionnement d’infrastructure depuis du code .NET.

Azure.AI.Projects 2.0.0 — Changements Cassants Qui Font Sens

Le paquet NuGet Azure.AI.Projects atteint la version stable 2.0.0: séparations de namespaces, types renommés, et convention Is* cohérente pour les booléens.

Cosmos DB Java : Correctif de Sécurité Critique (RCE)

La version 4.79.0 inclut un correctif critique pour une vulnérabilité d’exécution de code à distance (CWE-502). Mise à jour immédiate requise.

Nouvelles Bibliothèques de Provisioning pour .NET

Conclusion

Le point fort pour les développeurs .NET ce mois-ci : Azure.AI.Projects 2.0.0 est stable. Post original : Azure SDK Release (April 2026).

CodeAct dans Agent Framework : Comment Réduire la Latence de votre Agent de Moitié

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

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

Il y a ce moment dans tout projet d’agents où vous regardez la trace et pensez : « pourquoi est-ce que ça prend autant de temps ? » Le modèle est bien. Les outils fonctionnent. Mais il y a sept allers-retours pour obtenir un résultat qu’on pourrait calculer en une seule fois.

C’est exactement le problème que CodeAct résout — et l’équipe Agent Framework vient de publier un support alpha via le nouveau paquet agent-framework-hyperlight.

Qu’est-ce que CodeAct ?

Le pattern CodeAct est élégamment simple : au lieu de donner au modèle une liste d’outils à appeler un par un, vous lui donnez un seul outil execute_code et le laissez exprimer le plan complet comme un court programme Python. L’agent écrit le code une fois, le sandbox l’exécute, et vous récupérez un seul résultat consolidé.

Câblage	Temps	Tokens
Traditionnel	27,81s	6 890
CodeAct	13,23s	2 489
Amélioration	52,4%	63,9%

Sécurité : Micro-VMs Hyperlight

Le paquet agent-framework-hyperlight utilise des micro-VMs Hyperlight. Chaque appel execute_code obtient sa propre micro-VM fraîchement créée. Le démarrage se mesure en millisecondes. L’isolation est pratiquement gratuite.

Vos outils continuent de s’exécuter sur l’hôte. Le code de collage généré par le modèle s’exécute dans le sandbox. C’est le bon découpage.

Configuration minimale

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Quand utiliser CodeAct (et quand ne pas l’utiliser)

Utilisez CodeAct quand :

La tâche enchaîne de nombreux petits appels d’outils (lookups, jointures, calculs)
La latence et le coût en tokens comptent
Vous voulez une isolation forte par appel pour le code généré par le modèle

Restez avec le tool-calling traditionnel quand :

L’agent ne fait qu’un ou deux appels d’outils par tour
Chaque appel a des effets secondaires à approuver individuellement
Les descriptions d’outils sont peu détaillées

Essayez maintenant

pip install agent-framework-hyperlight --pre

Consultez le post complet sur le blog Agent Framework pour une couverture approfondie.

GPT-5.5 Est Là et Arrive dans Azure Foundry — Ce que les Développeurs .NET Doivent Savoir

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

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

Microsoft vient d’annoncer que GPT-5.5 est généralement disponible dans Microsoft Foundry. Si vous avez été en train de créer des agents sur Azure, c’est la mise à jour que vous attendiez.

La progression de GPT-5

GPT-5 : a unifié le raisonnement et la vitesse en un seul système
GPT-5.4 : raisonnement multi-étapes plus solide, capacités agentiques pour l’entreprise
GPT-5.5 : raisonnement en contexte long plus profond, exécution agentique plus fiable, meilleure efficacité des tokens

Ce qui a vraiment changé

Codage agentique amélioré : GPT-5.5 maintient le contexte sur de grandes bases de code, diagnostique les défaillances architecturales et anticipe les exigences de tests. Le modèle raisonne sur ce que d’autre une correction affecte avant d’agir.

Efficacité des tokens : Des sorties de meilleure qualité avec moins de tokens et moins de tentatives. Coût et latence directement réduits en production.

Analyse en contexte long : Gère de vastes documents et des historiques multi-sessions sans perdre le fil.

Tarification

Modèle	Entrée ($/M tokens)	Entrée en cache	Sortie ($/M tokens)
GPT-5.5	5,00 $	0,50 $	30,00 $
GPT-5.5 Pro	30,00 $	3,00 $	180,00 $

Pourquoi Foundry est important

Foundry Agent Service vous permet de définir des agents en YAML ou de les connecter avec Microsoft Agent Framework, GitHub Copilot SDK, LangGraph ou OpenAI Agents SDK — et de les exécuter comme agents hébergés isolés avec un système de fichiers persistant, une identité Microsoft Entra distincte et une tarification à l’échelle zéro.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Vous êtes un assistant utile.", name: "MonAgent");

Consultez l’annonce complète pour tous les détails.

Où votre Agent se Souvient-il des Choses ? Guide Pratique sur le Stockage de l'Historique de Chat

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

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

Lors de la création d’un agent IA, vous consacrez la majeure partie de votre énergie au modèle, aux outils et aux prompts. La question de l’endroit où vit l’historique des conversations semble être un détail d’implémentation — mais c’est l’une des décisions architecturales les plus importantes que vous prendrez.

Elle détermine si les utilisateurs peuvent bifurquer des conversations, annuler des réponses, reprendre des sessions après un redémarrage, et si vos données quittent jamais votre infrastructure. L’équipe Agent Framework a publié une analyse approfondie.

Deux modèles fondamentaux

Géré par le service : le service IA stocke l’état de la conversation. Votre application tient une référence et le service inclut automatiquement l’historique pertinent dans chaque requête.

Géré par le client : votre application maintient l’historique complet et envoie les messages pertinents avec chaque requête. Le service est sans état. Vous contrôlez tout.

Comment Agent Framework abstrait cela

// C# — fonctionne pareil quel que soit le fournisseur
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Je m'appelle Alice.", session);
var second = await agent.RunAsync("Quel est mon nom ?", session);

# Python
session = agent.create_session()
first = await agent.run("Je m'appelle Alice.", session=session)
second = await agent.run("Quel est mon nom ?", session=session)

Référence rapide des fournisseurs

Fournisseur	Stockage	Modèle	Compaction
OpenAI/Azure Chat Completions	Client	N/A	Vous
Foundry Agent Service	Service	Linéaire	Service
Responses API (défaut)	Service	Bifurquant	Service
Anthropic Claude, Ollama	Client	N/A	Vous

Comment choisir

Besoin de bifurcation ou « annuler » ? → Responses API géré par service
Besoin de souveraineté des données ? → Géré par client avec fournisseur base de données
Simple chatbot ? → Géré par service linéaire suffit

Lisez le post complet pour l’arbre de décision 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.

Aspire 13.2 : Support Bun, Meilleurs Conteneurs et Moins de Friction de Debug

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

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

Si vous construisez des backends .NET avec des frontends JavaScript dans Aspire, la 13.2 est la mise à jour qui améliore silencieusement votre quotidien. Des améliorations solides à des choses légèrement agaçantes.

Bun est Maintenant Citoyen de Première Classe

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

Si votre équipe utilise déjà Bun, Aspire ne vous force plus à aller à contre-courant.

Yarn Plus Fiable

Les utilisateurs de Yarn bénéficient de moins d’échecs mystérieux avec withYarn() et addViteApp().

Améliorations des Conteneurs

Pull policy explicite avec ImagePullPolicy.Never pour utiliser l’image locale sans aller au registry. PostgreSQL 18+ avec des volumes de données fonctionne maintenant correctement.

Améliorations du Débogage

DebuggerDisplayAttribute sur les types core
Meilleurs messages d’erreur pour WaitFor
BeforeResourceStartedEvent se déclenche au bon moment

Conclusion

Post original de David Pine : Aspire 13.2: Bun Support and Container Enhancements.

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

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

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

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

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

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

Le Mensonge de la Fenêtre de Contexte

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

Voici le calcul réel :

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

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

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

La Taxe de Compactage

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

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

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

pip install auto-memory

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

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

En Conclusion

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

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

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.

Patcher Immédiatement : Mise à Jour de Sécurité OOB .NET 10.0.7 pour ASP.NET Core Data Protection

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

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

Cette mise à jour n’est pas optionnelle. Si votre application utilise Microsoft.AspNetCore.DataProtection, vous devez mettre à jour vers 10.0.7.

Ce Qui S’est Passé

Après la version Patch Tuesday .NET 10.0.6, certains utilisateurs ont signalé des échecs de déchiffrement. En enquêtant, l’équipe a découvert CVE-2026-40372 : le tag HMAC était calculé sur les mauvais octets, pouvant mener à une élévation de privilèges.

Comment Corriger

dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7

Puis reconstruire et redéployer.

Annonce originale de Rahul Bhandari : .NET 10.0.7 Out-of-Band Security Update.

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

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

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

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

Configuration avec Copilot pendant azd init

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

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

Prérequis :

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

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

Ce que ça fait concrètement

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

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

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

Résolution d’erreurs avec Copilot

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

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

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

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

Configurer un comportement par défaut

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

azd config set copilot.errorHandling.category troubleshoot

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

azd config set copilot.errorHandling.fix allow

Retour au mode interactif à tout moment :

azd config unset copilot.errorHandling.category

Conclusion

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

Lis l’annonce originale ici.

Écrire des addons natifs Node.js en C# avec .NET Native AOT

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

Voilà un scénario que j’adore : une équipe qui travaille sur des outils .NET avait des addons natifs Node.js écrits en C++ et compilés via node-gyp. Ça fonctionnait. Mais ça nécessitait Python sur chaque machine de développeur — une vieille version de Python, par-dessus le marché — juste pour construire un package que personne dans l’équipe ne toucherait directement.

Ils se sont donc posé une question très raisonnable : on a déjà le SDK .NET installé, pourquoi écrit-on du C++ ?

La réponse était Native AOT, et le résultat est vraiment élégant. Drew Noakes de l’équipe C# Dev Kit a documenté comment ils l’ont fait, et je pense que ça vaut la peine de comprendre — même si tu ne construis pas d’extensions VS Code.

L’idée de base

Un addon natif Node.js est une bibliothèque partagée (.dll sous Windows, .so sous Linux, .dylib sous macOS) que Node.js peut charger au runtime. L’interface s’appelle N-API — une API C stable et compatible ABI. N-API se fiche du langage qui a produit la bibliothèque, tant qu’elle exporte les bons symboles.

.NET Native AOT peut produire exactement ça. Il compile le code C# en avance en une bibliothèque partagée native avec des points d’entrée arbitraires. C’est tout le truc.

Configuration du projet

Le fichier projet est minimal :

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot dit au SDK de produire une bibliothèque partagée à dotnet publish. AllowUnsafeBlocks est nécessaire pour l’interop N-API avec des pointeurs de fonctions et des buffers fixes.

Exporter le point d’entrée

Node.js s’attend à ce que ta bibliothèque exporte napi_register_module_v1. En C#, [UnmanagedCallersOnly] fait exactement ça :

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

Quelques points à noter : nint est un entier de taille native — l’équivalent managé de intptr_t. Le suffixe u8 produit un ReadOnlySpan<byte> avec un littéral de chaîne UTF-8, passé directement à N-API sans aucune allocation d’encodage. Et [UnmanagedCallersOnly] exporte la méthode avec exactement le nom de point d’entrée que Node.js cherche.

Résoudre N-API contre le processus hôte

Les fonctions N-API sont exportées par node.exe lui-même, pas une bibliothèque séparée. Donc au lieu de lier contre quelque chose, on les résout contre le processus en cours au démarrage :

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

Avec ça en place, les déclarations P/Invoke fonctionnent proprement avec [LibraryImport] et le marshalling généré par la source.

Une vraie fonction exportée

Voici le lecteur de registre qu’ils ont construit :

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

Note importante sur le try/catch : une exception non gérée dans une méthode [UnmanagedCallersOnly] plante le processus hôte. Toujours attraper et transmettre à JavaScript via ThrowError.

Appeler depuis TypeScript

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk', 'InstallLocation');

TypeScript → C#, sans Python, sans C++.

Ce qu’ils ont gagné

La victoire immédiate : l’expérience contributeur. Plus besoin d’une version Python spécifique, yarn install fonctionne avec Node.js et le SDK .NET. Les pipelines CI sont aussi plus simples. Les performances sont comparables à l’implémentation C++.

Conclusion

L’équipe C# Dev Kit a remplacé la complexité Python/C++ par du C# propre que toute l’équipe sait déjà écrire et déboguer. Pour le walkthrough complet avec tous les helpers de marshalling de chaînes, consulte l’article original sur le blog .NET.

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.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 a lieu le 18 avril 2026 au Kinépolis Diversia à Alcobendas, Madrid. C’est le plus grand événement communautaire Azure en Espagne, réunissant 38 speakers sur 3 tracks parallèles couvrant les agents IA, le réseau Azure, Cosmos DB, Fabric, IoT, la sécurité et bien plus.

L’événement se déroule de 08h30 à 18h30 et comprend une keynote, des pauses café, un déjeuner et une session de clôture Q&A.

Points forts de l’agenda

Domando Agentes de IA : gouvernance, outils et APIs avec Azure AI Foundry et Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis! : systèmes multi-agents en action
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Billets

L’inscription est une donation symbolique — le prix du billet est entièrement reversé à Plan International, soutenant les droits des enfants et l’égalité dans le monde. Capacité limitée, alors réservez votre place rapidement.

Azure Tour 2026

Au-delà de Madrid, le Global Azure Tour 2026 comprend également des étapes à Saragosse, Tenerife et Séville.

Le RFT de Foundry est désormais moins cher et plus intelligent — Voici ce qui a changé

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

Si vous développez des applications .NET qui reposent sur des modèles fine-tunés, les mises à jour Foundry de ce mois méritent votre attention. Le Reinforcement Fine-Tuning est devenu plus accessible et nettement moins cher.

Les détails complets sont dans l’annonce officielle, mais voici le résumé pratique.

Entraînement Global pour o4-mini

o4-mini est le modèle de référence pour les charges de travail intensives en raisonnement et agentiques. La grande nouvelle : vous pouvez désormais lancer des jobs de fine-tuning depuis plus de 13 régions Azure avec des tarifs d’entraînement par token inférieurs par rapport à l’entraînement Standard. Même infrastructure, même qualité, plus grande portée.

Si votre équipe est répartie géographiquement, c’est important. Vous n’êtes plus limité à une poignée de régions pour entraîner.

Voici l’appel API REST pour lancer un job d’entraînement global :

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Ce flag trainingType: globalstandard fait toute la différence.

Nouveaux Évaluateurs de Modèle : Famille GPT-4.1

Les évaluateurs définissent le signal de récompense contre lequel votre modèle optimise. Jusqu’à présent, les évaluateurs basés sur des modèles étaient limités à un ensemble restreint de modèles. Vous avez maintenant trois nouvelles options : GPT-4.1, GPT-4.1-mini et GPT-4.1-nano.

Quand faut-il utiliser des évaluateurs de modèle plutôt que des déterministes ? Quand la sortie de votre tâche est ouverte, quand vous avez besoin de notation partielle sur plusieurs dimensions, ou quand vous construisez des workflows agentiques où la justesse des appels d’outils dépend du contexte sémantique.

Le truc, c’est que la stratégie de niveaux est pratique :

GPT-4.1-nano pour les premières itérations. Coût faible, boucles de feedback rapides.
GPT-4.1-mini une fois que votre grille d’évaluation est stable et que vous avez besoin de plus de fidélité.
GPT-4.1 pour l’évaluation en production ou les grilles complexes où chaque décision de notation compte.

Vous pouvez même mixer les types d’évaluateurs dans un seul job RFT. Utilisez le string-match pour la dimension “bonne réponse” et un évaluateur de modèle pour évaluer la qualité du raisonnement. Cette flexibilité est honnêtement ce qui le rend utile pour des charges de travail réelles.

Le Piège du Format de Données RFT

C’est ce qui fait trébucher les gens. Le format de données RFT est différent du SFT. Le dernier message de chaque ligne doit avoir le rôle User ou Developer — pas Assistant. La réponse attendue va dans une clé de niveau supérieur comme reference_answer que l’évaluateur référence directement.

Si vous faisiez du supervised fine-tuning et que vous voulez passer au RFT, vous devez restructurer vos données d’entraînement. Ne sautez pas cette étape ou vos jobs échoueront silencieusement.

Pourquoi C’est Important pour les Développeurs .NET

Si vous appelez des modèles fine-tunés depuis vos applications .NET via le SDK Azure OpenAI, un entraînement moins cher signifie que vous pouvez itérer plus agressivement. Les options d’évaluateurs de modèle signifient que vous pouvez fine-tuner pour des tâches nuancées — pas seulement des scénarios de correspondance exacte. Et le guide de bonnes pratiques sur GitHub vous fera gagner un temps réel de débogage.

Commencez petit. Dix à cent échantillons. Évaluateur simple. Validez la boucle. Puis montez en charge.

Vos expériences IA sur Azure brûlent de l'argent — Voici comment y remédier

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

Si vous construisez des applications alimentées par l’IA sur Azure en ce moment, vous avez probablement remarqué quelque chose : votre facture cloud a changé. Pas juste plus élevée — plus bizarre. Avec des pics. Difficile à prévoir.

Microsoft vient de publier un excellent article sur les principes d’optimisation des coûts cloud qui comptent toujours, et honnêtement, le timing ne pourrait pas être meilleur. Parce que les charges de travail IA ont changé la donne en matière de coûts.

Pourquoi les charges de travail IA frappent différemment

Voilà le truc. Les charges de travail .NET traditionnelles sont relativement prévisibles. Vous connaissez votre niveau App Service, vous connaissez vos DTUs SQL, vous pouvez estimer les dépenses mensuelles assez précisément. Les charges de travail IA ? Pas vraiment.

Vous testez plusieurs modèles pour voir lequel convient. Vous démarrez de l’infrastructure GPU pour du fine-tuning. Vous faites des appels API à Azure OpenAI où la consommation de tokens varie énormément selon la longueur du prompt et le comportement des utilisateurs. Chaque expérience coûte de l’argent réel, et vous pourriez en mener des dizaines avant de trouver la bonne approche.

Cette imprévisibilité est ce qui rend l’optimisation des coûts critique — pas comme une réflexion après coup, mais dès le premier jour.

Gestion vs. optimisation — connaissez la différence

Une distinction de l’article que les développeurs négligent selon moi : il y a une différence entre la gestion des coûts et l’optimisation des coûts.

La gestion, c’est le suivi et le reporting. Vous configurez des budgets dans Azure Cost Management, vous recevez des alertes, vous consultez des tableaux de bord. C’est le minimum.

L’optimisation, c’est là que vous prenez réellement des décisions. Avez-vous vraiment besoin de ce tier S3, ou le S1 gérerait-il votre charge ? Cette instance de calcul toujours allumée est-elle inactive le week-end ? Pourriez-vous utiliser des instances spot pour vos jobs d’entraînement ?

En tant que développeurs .NET, nous avons tendance à nous concentrer sur le code et à laisser les décisions d’infrastructure à « l’équipe ops ». Mais si vous déployez sur Azure, ces décisions sont aussi les vôtres.

Ce qui fonctionne vraiment

En me basant sur l’article et ma propre expérience, voici ce qui fait la différence :

Sachez ce que vous dépensez et où. Taguez vos ressources. Sérieusement. Si vous ne pouvez pas identifier quel projet ou expérience mange votre budget, vous ne pouvez rien optimiser. Azure Cost Management avec un tagging approprié est votre meilleur allié.

Mettez des garde-fous avant d’expérimenter. Utilisez Azure Policy pour restreindre les SKUs coûteux dans les environnements dev/test. Définissez des limites de dépenses sur vos déploiements Azure OpenAI. N’attendez pas que la facture arrive pour réaliser que quelqu’un a laissé un cluster GPU tourner tout le week-end.

Dimensionnez en continu. Cette VM que vous avez choisie pendant le prototypage ? Elle est probablement inadaptée pour la production. Azure Advisor vous donne des recommandations — regardez-les vraiment. Faites une revue mensuelle, pas annuelle.

Pensez au cycle de vie. Les ressources de développement devraient s’éteindre. Les environnements de test n’ont pas besoin de tourner 24h/24. Utilisez des politiques d’arrêt automatique. Pour les charges de travail IA spécifiquement, envisagez des options serverless où vous payez par exécution au lieu de maintenir du calcul actif.

Mesurez la valeur, pas seulement le coût. Celle-ci est facile à oublier. Un modèle qui coûte plus cher mais fournit des résultats nettement meilleurs pourrait être le bon choix. L’objectif n’est pas de dépenser le moins possible — c’est de dépenser intelligemment.

Ce qu’il faut retenir

L’optimisation des coûts cloud n’est pas un nettoyage ponctuel. C’est une habitude. Et avec les charges de travail IA qui rendent les dépenses plus imprévisibles que jamais, prendre cette habitude tôt vous épargne des surprises douloureuses par la suite.

Si vous êtes un développeur .NET qui construit sur Azure, commencez à traiter votre facture cloud comme vous traitez votre code — révisez-la régulièrement, refactorisez quand ça devient désordonné, et ne déployez jamais sans comprendre ce que ça va vous coûter.

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.

Le clustering de pins arrive enfin dans .NET MAUI Maps — Une propriété, zéro prise de tête

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

Tu connais ce moment où tu charges une carte avec une centaine de pins et tout se transforme en une tache illisible ? Ouais, c’était ça l’expérience .NET MAUI Maps jusqu’à maintenant. C’est terminé.

David Ortinau vient d’annoncer que .NET MAUI 11 Preview 3 embarque le clustering de pins nativement sur Android et iOS/Mac Catalyst. Et le meilleur — c’est ridiculement simple à activer.

Une propriété pour les gouverner tous

<maps:Map IsClusteringEnabled="True" />

C’est tout. Les pins proches sont regroupés en clusters avec un badge de comptage. Zoom avant, ils s’expandent. Zoom arrière, ils se regroupent. Le genre de comportement que les utilisateurs attendent de n’importe quelle carte moderne — et maintenant tu l’obtiens avec une seule propriété.

Groupes de clustering indépendants

C’est là que ça devient intéressant. Tous les pins ne devraient pas se regrouper ensemble. Les cafés et les parcs sont des choses différentes, et ta carte devrait le savoir.

La propriété ClusteringIdentifier te permet de séparer les pins en groupes indépendants :

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

Les pins avec le même identifiant se regroupent ensemble. Des identifiants différents forment des clusters indépendants même quand ils sont géographiquement proches. Pas d’identifiant ? Groupe par défaut. Propre et prévisible.

Gestion des taps sur les clusters

Quand un utilisateur tape sur un cluster, tu reçois un événement ClusterClicked avec tout ce dont tu as besoin :

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

Les arguments de l’événement te donnent Pins (les pins du cluster), Location (le centre géographique) et Handled (à mettre sur true si tu veux surcharger le zoom par défaut). Simple, pratique, exactement ce qu’on attend.

Détails de plateforme à connaître

Sur Android, le clustering utilise un algorithme personnalisé basé sur une grille qui recalcule lors des changements de zoom — aucune dépendance externe. Sur iOS et Mac Catalyst, il exploite le support natif de MKClusterAnnotation de MapKit, ce qui signifie des animations fluides et natives de la plateforme.

C’est un de ces cas où l’équipe MAUI a fait le bon choix — s’appuyer sur la plateforme là où ça a du sens.

Pourquoi c’est important

Le clustering de pins a été l’une des fonctionnalités les plus demandées dans .NET MAUI (issue #11811), et pour une bonne raison. Chaque app qui affiche des emplacements sur une carte — suivi de livraisons, localisateurs de magasins, immobilier — en a besoin. Avant, il fallait le construire soi-même ou intégrer une bibliothèque tierce. Maintenant c’est intégré.

Pour nous développeurs .NET qui construisons des apps mobiles multiplateformes, c’est exactement le type d’amélioration de qualité de vie qui fait de MAUI un choix véritablement pratique pour les scénarios lourds en cartes.

Pour commencer

Installe .NET 11 Preview 3 et mets à jour le workload .NET MAUI. L’exemple Maps inclut une nouvelle page Clustering avec laquelle tu peux jouer tout de suite.

Va construire quelque chose avec — et laisse tes cartes enfin respirer.

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.

.NET Avril 2026 Servicing — Les correctifs de sécurité à appliquer dès aujourd'hui

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

Les mises à jour de maintenance d’avril 2026 pour .NET et .NET Framework sont disponibles, et celle-ci inclut des correctifs de sécurité que vous allez vouloir appliquer rapidement. Six CVEs corrigés, dont deux vulnérabilités d’exécution de code à distance (RCE).

Ce qui a été corrigé

Voici le résumé rapide :

CVE	Type	Affecte
CVE-2026-26171	Contournement de fonctionnalité de sécurité	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	Exécution de code à distance	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	Exécution de code à distance	.NET 10, 9, 8
CVE-2026-32203	Déni de service	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	Déni de service	.NET Framework 3.0–4.8.1
CVE-2026-32226	Déni de service	.NET Framework 2.0–4.8.1

Les deux CVEs RCE (CVE-2026-32178 et CVE-2026-33116) affectent le plus large éventail de versions .NET et devraient être la priorité.

Versions mises à jour

.NET 10 : 10.0.6
.NET 9 : 9.0.15
.NET 8 : 8.0.26

Toutes sont disponibles via les canaux habituels — dotnet.microsoft.com, images de conteneurs sur MCR et gestionnaires de paquets Linux.

Que faire

Mettez à jour vos projets et vos pipelines CI/CD vers les dernières versions corrigées. Si vous utilisez des conteneurs, récupérez les dernières images. Si vous êtes sur .NET Framework, consultez les notes de version .NET Framework pour les correctifs correspondants.

Pour ceux qui font tourner .NET 10 en production (c’est la version actuelle), 10.0.6 est une mise à jour obligatoire. Idem pour .NET 9.0.15 et .NET 8.0.26 si vous êtes sur ces versions LTS. Deux vulnérabilités RCE, ce n’est pas quelque chose qu’on reporte.

Aspire 13.2 accueille MongoDB EF Core et Azure Data Lake — Deux intégrations à essayer

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

Aspire 13.2 vient d’arriver avec deux nouvelles intégrations de bases de données qui méritent votre attention : MongoDB Entity Framework Core et Azure Data Lake Storage. Si vous vouliez utiliser EF Core avec MongoDB dans une app Aspire, ou si vous aviez besoin de connecter des workloads data lake avec du service discovery, cette version apporte les deux.

MongoDB rencontre EF Core dans Aspire

C’est celle qui m’enthousiasme le plus. Aspire supporte MongoDB depuis un moment, mais c’était toujours le driver brut — pas d’EF Core, pas de DbContext, pas de requêtes LINQ sur vos documents. Maintenant vous avez l’expérience complète d’EF Core avec MongoDB, plus les health checks automatiques et le service discovery d’Aspire.

La mise en place suit le pattern typique d’Aspire. Dans votre AppHost :

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Puis dans votre projet consommateur, ajoutez l’intégration EF Core :

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Et enregistrez votre DbContext :

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

À partir de là, c’est de l’EF Core standard. Définissez vos entités, utilisez votre DbContext comme vous le feriez avec n’importe quel autre provider. L’intégration gère le connection pooling, les traces OpenTelemetry et les health checks en arrière-plan.

Pour les développeurs .NET qui utilisaient MongoDB avec le driver brut et configuraient les connection strings manuellement, c’est une belle amélioration. Vous obtenez l’abstraction complète d’EF Core sans perdre le service discovery d’Aspire.

Azure Data Lake Storage entre dans la danse

Le deuxième ajout majeur est une intégration Azure Data Lake Storage (ADLS). Si vous construisez des pipelines de données, des processus ETL ou des plateformes d’analytique, vous pouvez maintenant connecter des ressources Data Lake de la même façon que n’importe quelle autre dépendance Aspire.

Dans l’AppHost :

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Dans le projet consommateur :

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Pas de gestion manuelle de connection strings, pas de recherche de credentials. Aspire provisionne les ressources et les injecte. Pour ceux d’entre nous qui construisent des apps .NET cloud-native touchant à la fois aux données opérationnelles et aux workloads analytiques, cela fait du data lake un citoyen de première classe dans le modèle Aspire.

Les petits correctifs qui comptent

Au-delà des fonctionnalités principales, il y a quelques améliorations à noter :

Correction du connection string MongoDB — le slash avant le nom de la base de données est maintenant géré correctement. Si vous aviez un workaround, vous pouvez le supprimer
Exports SQL Server — Aspire.Hosting.SqlServer exporte maintenant des options de configuration serveur supplémentaires pour un contrôle plus fin
Mises à jour des émulateurs — émulateur ServiceBus 2.0.0, émulateur App Configuration 1.0.2, et l’émulateur preview de CosmosDB inclut maintenant une vérification de disponibilité
Azure Managed Redis — utilise maintenant rediss:// (Redis Secure) par défaut, donc les connexions sont chiffrées d’emblée

Ce dernier point est subtil mais important — un Redis chiffré par défaut signifie une chose de moins à configurer en production.

Pour conclure

Aspire 13.2 est une version incrémentale, mais les intégrations MongoDB EF Core et Data Lake comblent de vrais manques. Si vous attendiez un support EF Core correct avec MongoDB dans Aspire, ou si vous aviez besoin que Data Lake soit une dépendance de première classe, passez à la 13.2 et essayez-les. La commande aspire add génère tout ce dont vous avez besoin.

Lisez les notes de version complètes pour plus de détails, et consultez la galerie d’intégrations pour la liste complète.

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.

Azure DevOps Server Patch Avril 2026 — Correction du Complétion de PR et Mises à Jour de Sécurité

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

Petit rappel pour les équipes qui hébergent leur propre Azure DevOps Server : Microsoft a publié le Patch 3 d’avril 2026 avec trois correctifs ciblés.

Ce qui a été corrigé

Échecs de complétion des pull requests — une exception de référence nulle lors de l’auto-complétion des work items pouvait faire échouer les merges de PR. Si vous avez rencontré des erreurs aléatoires lors de la complétion de PR, c’est probablement la cause
Validation de la redirection à la déconnexion — validation améliorée lors de la déconnexion pour empêcher d’éventuelles redirections malveillantes. C’est un correctif de sécurité à appliquer rapidement
Connexions PAT vers GitHub Enterprise Server — la création de connexions par Personal Access Token vers GitHub Enterprise Server était cassée, c’est maintenant rétabli

Comment mettre à jour

Téléchargez le Patch 3 et lancez l’installateur. Pour vérifier que le patch est bien appliqué :

<patch-installer>.exe CheckInstall

Si vous utilisez Azure DevOps Server en auto-hébergement, Microsoft recommande vivement de rester sur le dernier patch pour la sécurité comme pour la fiabilité. Consultez les notes de version pour tous les détails.

Azure Smart Tier est en GA — Optimisation automatique des coûts de Blob Storage sans règles de cycle de vie

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

Si vous avez déjà passé du temps à peaufiner les politiques de cycle de vie d’Azure Blob Storage pour ensuite les voir s’effondrer quand les patterns d’accès ont changé, ceci est pour vous. Microsoft vient d’annoncer la disponibilité générale du smart tier pour Azure Blob et Data Lake Storage — une capacité de tiering entièrement gérée qui déplace automatiquement les objets entre les niveaux hot, cool et cold en fonction de l’utilisation réelle.

Ce que fait réellement le smart tier

Le concept est simple : le smart tier évalue en continu la dernière heure d’accès de chaque objet dans votre compte de stockage. Les données fréquemment consultées restent en hot, les données inactives passent en cool après 30 jours, puis en cold après 60 jours supplémentaires. Quand les données sont à nouveau consultées, elles sont repromues en hot immédiatement. Le cycle recommence.

Pas de règles de cycle de vie à configurer. Pas de prédictions de patterns d’accès. Pas de réglages manuels.

Pendant la preview, Microsoft a rapporté que plus de 50% de la capacité gérée par smart tier s’est automatiquement déplacée vers des niveaux plus froids en fonction des patterns d’accès réels. C’est une réduction de coûts significative pour les comptes de stockage volumineux.

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

Si vous développez des applications qui génèrent des logs, de la télémétrie, des données analytiques, ou tout type de patrimoine de données en croissance — et soyons honnêtes, qui ne le fait pas ? — les coûts de stockage s’accumulent vite. L’approche traditionnelle consistait à écrire des politiques de gestion de cycle de vie, les tester, puis les réajuster quand les patterns d’accès de votre application changeaient. Smart tier supprime entièrement ce workflow.

Quelques scénarios pratiques où cela aide :

Télémétrie et logs d’applications — hot lors du débogage, rarement consultés après quelques semaines
Pipelines de données et sorties ETL — sollicités intensément pendant le traitement, puis majoritairement cold
Contenu généré par les utilisateurs — les uploads récents sont hot, le contenu ancien refroidit progressivement
Données de sauvegarde et d’archivage — consultées occasionnellement pour la conformité, majoritairement inactives

Configuration

Activer le smart tier est une configuration unique :

Nouveaux comptes : Sélectionnez smart tier comme niveau d’accès par défaut lors de la création du compte de stockage (redondance zonale requise)
Comptes existants : Changez le niveau d’accès blob de votre valeur par défaut actuelle vers smart tier

Les objets de moins de 128 KiB restent en hot et n’engendrent pas de frais de surveillance. Pour tout le reste, vous payez les tarifs standard de capacité hot/cool/cold sans frais de transition de niveau, sans pénalités de suppression anticipée et sans coûts de récupération de données. Des frais de surveillance mensuels par objet couvrent l’orchestration.

Le compromis à connaître

Les règles de tiering du smart tier sont statiques (30 jours → cool, 90 jours → cold). Si vous avez besoin de seuils personnalisés — par exemple, passer en cool après 7 jours pour un workload spécifique — les règles de cycle de vie restent la solution. Et ne mélangez pas les deux : évitez d’utiliser des règles de cycle de vie sur des objets gérés par smart tier, car elles peuvent entrer en conflit.

Pour conclure

Ce n’est pas révolutionnaire, mais ça résout un vrai casse-tête opérationnel. Si vous gérez des comptes blob storage en croissance et que vous en avez assez de maintenir des politiques de cycle de vie, activez smart tier et laissez Azure s’en charger. C’est disponible dès aujourd’hui dans la quasi-totalité des régions zonales du cloud public.

Où héberger vos agents IA sur Azure ? Un guide de décision pratique

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

Si vous construisez des agents IA avec .NET en ce moment, vous avez probablement remarqué quelque chose : il y a beaucoup de façons de les héberger sur Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — et tous semblent raisonnables jusqu’à ce que vous ayez réellement besoin d’en choisir un. Microsoft vient de publier un guide complet sur l’hébergement d’agents IA sur Azure qui clarifie tout ça, et je veux le décomposer du point de vue pratique d’un développeur .NET.

Les six options en un coup d’œil

Voici comment je résumerais le paysage :

Option	Idéal pour	Vous gérez
Container Apps	Contrôle total des conteneurs sans complexité K8s	Observabilité, état, cycle de vie
AKS	Conformité entreprise, multi-cluster, réseau personnalisé	Tout (c’est le but)
Azure Functions	Tâches d’agents événementielles et courtes	Presque rien — vrai serverless
App Service	Agents HTTP simples, trafic prévisible	Déploiement, config de scaling
Foundry Agents	Agents sans code via portail/SDK	Presque rien
Foundry Hosted Agents	Agents framework personnalisé avec infra gérée	Uniquement votre code d’agent

Les quatre premières sont du compute généraliste — vous pouvez y exécuter des agents, mais elles n’ont pas été conçues pour ça. Les deux dernières sont natives aux agents : elles comprennent les conversations, les appels d’outils et les cycles de vie des agents comme des concepts de première classe.

Foundry Hosted Agents — le sweet spot pour les développeurs .NET d’agents

C’est ce qui a attiré mon attention. Les Foundry Hosted Agents se situent pile au milieu : vous obtenez la flexibilité d’exécuter votre propre code (Semantic Kernel, Agent Framework, LangGraph — peu importe) mais la plateforme gère l’infrastructure, l’observabilité et la gestion des conversations.

La pièce clé est le Hosting Adapter — une fine couche d’abstraction qui connecte votre framework d’agents à la plateforme Foundry. Pour Microsoft Agent Framework, ça ressemble à ça :

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

C’est toute votre histoire d’hébergement. L’adapter gère la traduction de protocoles, le streaming via server-sent events, l’historique de conversation et le traçage OpenTelemetry — tout automatiquement. Pas de middleware personnalisé, pas de plomberie manuelle.

Le déploiement est vraiment simple

J’ai déployé des agents sur Container Apps avant et ça fonctionne, mais on finit par écrire beaucoup de code de colle pour la gestion d’état et l’observabilité. Avec Hosted Agents et azd, le déploiement c’est :

# Installer l'extension agent IA
azd ext install azure.ai.agents

# Initialiser depuis un template
azd ai agent init

# Construire, pousser, déployer — terminé
azd up

Ce seul azd up construit votre conteneur, le pousse vers ACR, provisionne le projet Foundry, déploie les endpoints de modèle et démarre votre agent. Cinq étapes condensées en une seule commande.

Gestion de conversations intégrée

C’est la partie qui fait gagner le plus de temps en production. Au lieu de construire votre propre store d’état de conversation, les Hosted Agents le gèrent nativement :

# Créer une conversation persistante
conversation = openai_client.conversations.create()

# Premier tour
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Deuxième tour — le contexte est préservé
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Pas de Redis. Pas de store de sessions Cosmos DB. Pas de middleware personnalisé pour la sérialisation des messages. La plateforme gère tout simplement.

Mon framework de décision

Après avoir passé en revue les six options, voici mon modèle mental rapide :

Vous avez besoin de zéro infrastructure ? → Foundry Agents (portail/SDK, pas de conteneurs)
Vous avez du code d’agent personnalisé mais voulez un hébergement géré ? → Foundry Hosted Agents
Vous avez besoin de tâches d’agents événementielles et courtes ? → Azure Functions
Vous avez besoin d’un contrôle maximum des conteneurs sans K8s ? → Container Apps
Vous avez besoin de conformité stricte et multi-cluster ? → AKS
Vous avez un agent HTTP simple avec un trafic prévisible ? → App Service

Pour la plupart des développeurs .NET qui construisent avec Semantic Kernel ou Microsoft Agent Framework, Hosted Agents est probablement le bon point de départ. Vous obtenez le scale-to-zero, OpenTelemetry intégré, la gestion des conversations et la flexibilité de framework — sans gérer Kubernetes ni monter votre propre stack d’observabilité.

Pour conclure

Le paysage de l’hébergement d’agents sur Azure mûrit rapidement. Si vous démarrez un nouveau projet d’agent IA aujourd’hui, je considérerais sérieusement Foundry Hosted Agents avant de recourir à Container Apps ou AKS par habitude. L’infrastructure gérée fait gagner un temps réel, et le pattern hosting adapter vous permet de garder votre choix de framework.

Consultez le guide complet de Microsoft et le repo Foundry Samples pour des exemples fonctionnels.

Les Agent Skills en .NET deviennent vraiment flexibles

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

Si vous construisez des agents avec le Microsoft Agent Framework, vous connaissez le principe : vous définissez des skills, vous les connectez à un provider et vous laissez l’agent décider lequel invoquer. Ce qui est nouveau, c’est comment vous créez ces skills — et le gain en flexibilité est significatif.

La dernière mise à jour introduit trois patterns d’authoring pour les agent skills : basées sur des fichiers, basées sur des classes et définies en code inline. Les trois se branchent sur un seul AgentSkillsProviderBuilder, ce qui veut dire que vous pouvez les mixer sans logique de routage ni code spécial. Je vous présente chacune et quand l’utiliser.

Skills basées sur des fichiers : le point de départ

Les skills basées sur des fichiers sont exactement ce que leur nom suggère — un répertoire sur disque avec un fichier SKILL.md, des scripts optionnels et des documents de référence. La façon la plus directe de donner de nouvelles capacités à votre agent :

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

Le frontmatter du SKILL.md déclare le nom et la description, et la section d’instructions dit à l’agent comment utiliser les scripts et les références :

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Ensuite vous le connectez avec SubprocessScriptRunner.RunAsync pour l’exécution des scripts :

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

L’agent découvre la skill automatiquement et invoque le script de provisioning quand il doit vérifier le statut des comptes. Propre et simple.

Skills basées sur des classes : distribuer via NuGet

C’est là que ça devient intéressant pour les équipes. Les skills basées sur des classes dérivent de AgentClassSkill<T> et utilisent des attributs comme [AgentSkillResource] et [AgentSkillScript] pour que le framework découvre tout par réflexion :

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Le beau ici, c’est qu’une équipe peut packager ça en paquet NuGet. Vous l’ajoutez à votre projet, vous le mettez dans le builder, et ça fonctionne à côté de vos skills fichier sans coordination :

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Les deux skills apparaissent dans le system prompt de l’agent. L’agent décide laquelle utiliser en fonction de la conversation — pas de code de routage nécessaire.

Skills inline : le pont rapide

Vous connaissez ce moment où une autre équipe construit exactement la skill dont vous avez besoin, mais elle ne sera pas prête avant le prochain sprint ? AgentInlineSkill est votre pont :

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Ajoutez-la au builder comme les autres :

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Quand le paquet NuGet sort enfin, vous échangez la skill inline contre la version classe. L’agent ne voit pas la différence.

Les skills inline ne sont pas que pour les ponts. Elles sont aussi le bon choix quand vous devez générer des skills dynamiquement à l’exécution — pensez à une skill par unité métier chargée depuis la config — ou quand un script doit capturer un état local qui n’a pas sa place dans un conteneur DI.

Approbation de scripts : l’humain dans la boucle

Pour nous développeurs .NET qui construisons des agents de production, c’est la partie qui débloque vraiment les discussions de déploiement. Certains scripts ont des conséquences réelles — inscrire quelqu’un à des avantages, interroger l’infrastructure de production. Activez UseScriptApproval et l’agent se met en pause avant d’exécuter tout script :

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Quand l’agent veut exécuter un script, il retourne une demande d’approbation à la place. Votre app collecte la décision — approuver ou rejeter — et l’agent continue en conséquence. Dans les environnements réglementés, c’est la différence entre “on peut déployer ça” et “le juridique dit non.”

Pourquoi cette combinaison compte

Le vrai pouvoir n’est pas dans un pattern individuel — c’est dans la composition. Vous pouvez :

Commencer petit avec une skill fichier, itérer sur les instructions et la publier sans écrire de C#
Distribuer des skills réutilisables comme paquets NuGet que d’autres équipes ajoutent en une ligne
Combler les lacunes avec des skills inline quand vous avez besoin de quelque chose maintenant
Filtrer les répertoires partagés avec des prédicats pour que votre agent ne charge que ce qu’il doit
Ajouter une supervision humaine pour les scripts qui touchent les systèmes de production

Tout cela se compose via AgentSkillsProviderBuilder. Pas de routage spécial, pas de logique conditionnelle, pas de vérifications de type de skill.

Pour conclure

Les agent skills en .NET ont maintenant un modèle d’authoring véritablement flexible. Que vous soyez un développeur solo qui prototype avec des skills fichier ou une équipe enterprise qui distribue des capacités packagées via NuGet, les patterns s’adaptent. Et le mécanisme d’approbation de scripts le rend prêt pour la production dans les environnements où vous avez besoin de ce checkpoint humain.

Consultez l’annonce originale, la documentation Agent Skills sur Microsoft Learn et les exemples .NET sur GitHub pour vous lancer.

Azure MCP Server 2.0 Est Arrivé — L'Automatisation Agentic Self-Hosted Est Ici

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

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

Si vous avez construit quelque chose avec MCP et Azure récemment, vous savez probablement que l’expérience locale fonctionne bien. Branchez un serveur MCP, laissez votre agent IA parler aux ressources Azure, et passez à la suite. Mais dès que vous avez besoin de partager cette configuration dans une équipe ? C’est là que les choses se compliquaient.

Plus maintenant. Azure MCP Server vient d’atteindre la version 2.0 stable, et la fonctionnalité phare est exactement ce que les équipes d’entreprise demandaient : le support du serveur MCP distant self-hosted.

Qu’est-ce qu’Azure MCP Server ?

Petit rappel. Azure MCP Server implémente la spécification Model Context Protocol et expose les capacités Azure en tant qu’outils structurés et découvrables que les agents IA peuvent invoquer. Pensez-y comme un pont standardisé entre votre agent et Azure — provisionnement, déploiement, monitoring, diagnostics, tout par une interface cohérente.

Les chiffres parlent d’eux-mêmes : 276 outils MCP sur 57 services Azure. C’est une couverture sérieuse.

Le grand changement : les déploiements distants self-hosted

Voici la chose. Exécuter MCP localement sur votre machine, c’est bien pour le développement et les expériences. Mais dans un scénario d’équipe réelle, vous avez besoin de :

Un accès partagé pour les développeurs et les systèmes d’agents internes
Une configuration centralisée (contexte de tenant, valeurs par défaut des abonnements, télémétrie)
Des limites de réseau et de politique d’entreprise
L’intégration dans les pipelines CI/CD

Azure MCP Server 2.0 s’adresse à tout cela. Vous pouvez le déployer comme un service interne géré de manière centralisée avec un transport basé sur HTTP, une authentification appropriée et une gouvernance cohérente.

Pour l’authentification, vous avez deux excellentes options :

Managed Identity — lors de l’exécution aux côtés de Microsoft Foundry
Le flux On-Behalf-Of (OBO) — une délégation OpenID Connect qui appelle les API Azure en utilisant le contexte de l’utilisateur connecté

Ce flux OBO est particulièrement intéressant pour nous, développeurs .NET. Cela signifie que vos workflows agentiques peuvent fonctionner avec les permissions réelles de l’utilisateur, pas un compte de service surprivilégié. Le principe du moindre privilège, intégré nativement.

Renforcement de la sécurité

Ce n’est pas seulement une sortie de fonctionnalité — c’est aussi une sortie de sécurité. La version 2.0 ajoute :

Une validation d’endpoint plus forte
Des protections contre les modèles d’injection dans les outils orientés requête
Des contrôles d’isolation plus serrés pour les environnements de développement

Si vous allez exposer MCP comme un service partagé, ces protections sont importantes. Vraiment importantes.

Où pouvez-vous l’utiliser ?

L’histoire de compatibilité des clients est large. Azure MCP Server 2.0 fonctionne avec :

IDEs : VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
Agents CLI : GitHub Copilot CLI, Claude Code
Standalone : serveur local pour les configurations simples
Self-hosted distant : la nouvelle vedette de la version 2.0

Plus il y a le support du cloud souverain pour Azure US Government et Azure exploité par 21Vianet, ce qui est critique pour les déploiements réglementés.

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

Si vous construisez des applications agentiques avec .NET — qu’il s’agisse de Semantic Kernel, Microsoft Agent Framework, ou votre propre orchestration — Azure MCP Server 2.0 vous donne un moyen prêt pour la production de laisser vos agents interagir avec l’infrastructure Azure. Pas de wrappers REST personnalisés. Pas de modèles d’intégration spécifiques aux services. Juste MCP.

Combiné avec l’API fluide pour les applications MCP qui est arrivée il y a quelques jours, l’écosystème .NET MCP mûrit rapidement.

Démarrage

Choisissez votre chemin :

GitHub Repo — code source, documentation, tout
Image Docker — déploiement containerisé
Extension VS Code — intégration IDE
Guide de self-hosting — la fonctionnalité phare de la version 2.0

Conclusion

Azure MCP Server 2.0 est exactement le type de mise à niveau d’infrastructure qui ne brille pas dans une démo mais change tout en pratique. Un MCP distant self-hosted avec une authentification appropriée, un renforcement de la sécurité et un support du cloud souverain signifient que MCP est prêt pour les vraies équipes construisant de vrais workflows agentiques sur Azure. Si vous attendiez le signal « prêt pour l’entreprise » — c’est celui-ci.

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

Connectez vos serveurs MCP sur Azure Functions aux agents Foundry — Voici comment

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

Voici ce que j’adore dans l’écosystème MCP : vous construisez votre serveur une fois, et il fonctionne partout. VS Code, Visual Studio, Cursor, ChatGPT — chaque client MCP peut découvrir et utiliser vos outils. Maintenant, Microsoft ajoute un autre consommateur à cette liste : les agents Foundry.

Lily Ma de l’équipe Azure SDK a publié un guide pratique sur la connexion de serveurs MCP déployés sur Azure Functions avec les agents Microsoft Foundry. Si vous avez déjà un serveur MCP, c’est de la valeur ajoutée pure — aucune reconstruction nécessaire.

Pourquoi cette combinaison a du sens

Azure Functions vous offre une infrastructure évolutive, une authentification intégrée et une facturation serverless pour héberger des serveurs MCP. Microsoft Foundry vous offre des agents IA capables de raisonner, planifier et agir. Les connecter signifie que vos outils personnalisés — interroger une base de données, appeler une API métier, exécuter une logique de validation — deviennent des capacités que les agents IA d’entreprise peuvent découvrir et utiliser de manière autonome.

Le point clé : votre serveur MCP reste le même. Vous ajoutez simplement Foundry comme un autre consommateur. Les mêmes outils qui fonctionnent dans votre configuration VS Code alimentent maintenant un agent IA avec lequel votre équipe ou vos clients interagissent.

Options d’authentification

C’est là que l’article apporte vraiment de la valeur. Quatre méthodes d’authentification selon votre scénario :

Méthode	Cas d’usage
Basée sur clé (par défaut)	Développement ou serveurs sans auth Entra
Microsoft Entra	Production avec identités managées
Passthrough d’identité OAuth	Production où chaque utilisateur s’authentifie individuellement
Sans authentification	Dev/tests ou données publiques uniquement

Pour la production, Microsoft Entra avec identité d’agent est le chemin recommandé. Le passthrough d’identité OAuth est pour les cas où le contexte utilisateur compte — l’agent demande aux utilisateurs de se connecter, et chaque requête porte le propre token de l’utilisateur.

Mise en place

Le flux général :

Déployez votre serveur MCP sur Azure Functions — des exemples sont disponibles pour .NET, Python, TypeScript et Java
Activez l’authentification MCP intégrée sur votre function app
Obtenez votre URL d’endpoint — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Ajoutez le serveur MCP comme outil dans Foundry — naviguez vers votre agent dans le portail, ajoutez un nouvel outil MCP, fournissez l’endpoint et les credentials

Testez ensuite dans le playground de l’Agent Builder en envoyant un prompt qui déclenchera l’un de vos outils.

Mon avis

L’histoire de la composabilité devient vraiment solide ici. Construisez votre serveur MCP une fois en .NET (ou Python, TypeScript, Java), déployez-le sur Azure Functions, et chaque client compatible MCP peut l’utiliser — outils de programmation, apps de chat, et maintenant agents IA d’entreprise. C’est un pattern « écrire une fois, utiliser partout » qui fonctionne réellement.

Pour les développeurs .NET spécifiquement, l’extension MCP Azure Functions rend les choses simples. Vous définissez vos outils comme des Azure Functions, vous déployez, et vous avez un serveur MCP prêt pour la production avec toute la sécurité et la scalabilité qu’Azure Functions fournit.

Pour conclure

Si vous avez des outils MCP qui tournent sur Azure Functions, les connecter aux agents Foundry est un gain rapide — vos outils personnalisés deviennent des capacités IA d’entreprise avec une authentification appropriée et sans modification de code côté serveur.

Lisez le guide complet pour des instructions pas à pas sur chaque méthode d’authentification, et consultez la documentation détaillée pour les configurations de production.

Construire des UIs Multi-Agents en Temps Réel Qui Ne Ressemblent Pas à une Boîte Noire

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

Voilà le truc avec les systèmes multi-agents : ils sont incroyables en démo. Trois agents qui se passent le travail, résolvent des problèmes, prennent des décisions. Puis tu essaies de le mettre devant de vrais utilisateurs et… silence. Un indicateur qui tourne. Aucune idée de quel agent fait quoi ni pourquoi le système est en pause. Ce n’est pas un produit — c’est un problème de confiance.

L’équipe Microsoft Agent Framework vient de publier un excellent tutoriel sur le couplage des workflows MAF avec AG-UI, un protocole ouvert pour streamer les événements d’exécution des agents vers un frontend via les Server-Sent Events. Et franchement ? C’est exactement le pont qui nous manquait.

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

Si tu construis des applications alimentées par l’IA, tu as probablement déjà heurté ce mur. Ton orchestration backend fonctionne parfaitement — les agents se passent le relais, les outils se déclenchent, les décisions sont prises. Mais le frontend n’a aucune idée de ce qui se passe en coulisses. AG-UI résout ça en définissant un protocole standard pour streamer les événements d’agents (pense à RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) directement vers ta couche UI via SSE.

La démo est un workflow de support client avec trois agents : un agent de triage qui route les demandes, un agent de remboursement qui gère les questions d’argent, et un agent de commandes qui gère les remplacements. Chaque agent a ses propres outils, et la topologie de handoff est définie explicitement — pas de « devine à partir du prompt ».

La topologie de handoff est la vraie star

Ce qui m’a marqué, c’est comment HandoffBuilder te permet de déclarer un graphe de routage dirigé entre les agents :

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Chaque add_handoff crée une arête dirigée avec une description en langage naturel. Le framework génère des outils de handoff pour chaque agent en se basant sur cette topologie. Les décisions de routage reposent donc sur ta structure d’orchestration, pas juste sur ce que le LLM a envie de faire. C’est un gain énorme pour la fiabilité en production.

Le human-in-the-loop qui fonctionne vraiment

La démo présente deux patterns d’interruption dont toute app d’agents réelle a besoin :

Interruptions d’approbation d’outils — quand un agent appelle un outil marqué avec approval_mode="always_require", le workflow se met en pause et émet un événement. Le frontend affiche un modal d’approbation avec le nom de l’outil et ses arguments. Pas de boucles de retry qui brûlent des tokens — juste un flux propre pause-approbation-reprise.

Interruptions de demande d’information — quand un agent a besoin de plus de contexte de la part de l’utilisateur (comme un ID de commande), il se met en pause et pose la question. Le frontend affiche la question, l’utilisateur répond, et l’exécution reprend exactement là où elle s’était arrêtée.

Les deux patterns sont streamés en tant qu’événements AG-UI standard, donc ton frontend n’a pas besoin de logique personnalisée par agent — il affiche simplement chaque événement qui arrive via la connexion SSE.

L’intégration est étonnamment simple

L’intégration entre MAF et AG-UI se résume à un seul appel de fonction :

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

La workflow_factory crée un workflow frais par thread, pour que chaque conversation ait son propre état isolé. L’endpoint gère toute la plomberie SSE automatiquement. Si tu utilises déjà FastAPI (ou que tu peux l’ajouter comme couche légère), c’est quasiment zéro friction.

Mon avis

Pour nous développeurs .NET, la question immédiate est : « Est-ce que je peux faire ça en C# ? » L’Agent Framework est disponible pour .NET et Python, et le protocole AG-UI est agnostique au langage (c’est juste du SSE). Donc même si cette démo spécifique utilise Python et FastAPI, le pattern se transpose directement. Tu pourrais câbler une API minimale ASP.NET Core avec des endpoints SSE suivant le même schéma d’événements AG-UI.

Le point plus important est que les UIs multi-agents deviennent une préoccupation de premier plan, pas un ajout après coup. Si tu construis quoi que ce soit où des agents interagissent avec des humains — support client, workflows d’approbation, traitement de documents — cette combinaison d’orchestration MAF et de transparence AG-UI est le pattern à suivre.

Pour conclure

AG-UI + Microsoft Agent Framework te donne le meilleur des deux mondes : une orchestration multi-agents robuste côté backend et une visibilité en temps réel côté frontend. Fini les interactions d’agents en boîte noire.

Consulte le tutoriel complet et le dépôt du protocole AG-UI pour aller plus loin.

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

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

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

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

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

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

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

Deux façons de commencer

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

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

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

Le détail des issues est actionnable

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

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

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

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

Les chemins de mise à jour couverts

Pour .NET spécifiquement :

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

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

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

Mon avis

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

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

Pour conclure

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

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

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

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

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

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

Ce que Git-APE fait concrètement

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

Voici la mise en place :

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

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

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

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

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

Pourquoi c’est important

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

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

Le nettoyage est tout aussi simple :

@git-ape destroy my-resource-group

Mon avis

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

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

Pour conclure

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

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

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.

Les MCP Apps ont une API fluide — Créez des interfaces riches pour outils IA en .NET en trois étapes

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

Les outils MCP sont parfaits pour donner des capacités aux agents IA. Mais que faire si votre outil doit montrer quelque chose à l’utilisateur — un tableau de bord, un formulaire, une visualisation interactive ? C’est là qu’interviennent les MCP Apps, et elles sont devenues beaucoup plus faciles à créer.

Lilian Kasem de l’équipe Azure SDK a présenté la nouvelle API de configuration fluide pour les MCP Apps sur Azure Functions .NET, et c’est le genre d’amélioration de l’expérience développeur qui fait se demander pourquoi ce n’était pas déjà aussi simple.

Qu’est-ce que les MCP Apps ?

Les MCP Apps étendent le Model Context Protocol en permettant aux outils d’embarquer leurs propres vues UI, assets statiques et contrôles de sécurité. Au lieu de simplement retourner du texte, votre outil MCP peut rendre des expériences HTML complètes — tableaux de bord interactifs, visualisations de données, formulaires de configuration — le tout invocable par des agents IA et présenté aux utilisateurs par les clients MCP.

Le problème était que tout câbler manuellement nécessitait une connaissance approfondie de la spécification MCP : URIs ui://, types MIME spéciaux, coordination des métadonnées entre outils et ressources. Pas difficile, mais fastidieux.

L’API fluide en trois étapes

Étape 1 : Définissez votre fonction. Un outil MCP Azure Functions standard :

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Étape 2 : Promouvez-la en MCP App. Dans le démarrage de votre programme :

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Étape 3 : Ajoutez votre vue HTML. Créez assets/hello-app.html avec l’interface dont vous avez besoin.

C’est tout. L’API fluide gère toute la plomberie du protocole MCP — génère la fonction de ressource synthétique, définit le type MIME correct et injecte les métadonnées qui connectent votre outil à sa vue.

La surface de l’API est bien conçue

Quelques éléments que j’apprécie particulièrement :

Les sources de vues sont flexibles. Vous pouvez servir du HTML depuis des fichiers sur disque ou intégrer des ressources directement dans votre assembly pour des déploiements autonomes :

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

Le CSP est composable. Vous autorisez explicitement les origines dont votre app a besoin, en suivant le principe du moindre privilège. Appelez WithCsp plusieurs fois et les origines s’accumulent :

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Contrôle de visibilité. Vous pouvez rendre un outil visible uniquement pour le LLM, uniquement pour l’UI de l’hôte, ou les deux. Vous voulez un outil qui ne fait que rendre de l’UI et ne devrait pas être appelé par le modèle ? Facile :

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Pour commencer

Ajoutez le package preview :

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Si vous construisez déjà des outils MCP avec Azure Functions, c’est juste une mise à jour de package. Le quickstart MCP Apps est le meilleur point de départ si vous découvrez le concept.

Pour conclure

Les MCP Apps sont l’un des développements les plus passionnants dans l’espace des outils IA — des outils qui ne font pas que faire des choses mais peuvent aussi montrer des choses aux utilisateurs. L’API fluide supprime la complexité du protocole et vous permet de vous concentrer sur l’essentiel : la logique de votre outil et son interface.

Lisez le post complet pour la référence complète de l’API et des exemples.

Microsoft Foundry Mars 2026 — GPT-5.4, Agent Service en GA et la Refonte du SDK Qui Change Tout

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

Les posts mensuels « Quoi de neuf dans Microsoft Foundry » sont généralement un mélange d’améliorations incrémentales et de fonctionnalités phares occasionnelles. L’édition de mars 2026 ? C’est pratiquement que des fonctionnalités phares. Foundry Agent Service passe en GA, GPT-5.4 arrive en production, le SDK reçoit une version stable majeure, et Fireworks AI apporte l’inférence de modèles ouverts sur Azure. Voyons ce qui compte pour les développeurs .NET.

Foundry Agent Service est prêt pour la production

C’est la grande nouvelle. Le runtime d’agents de nouvelle génération est en disponibilité générale — construit sur l’API Responses d’OpenAI, compatible au niveau du protocole avec les agents OpenAI, et ouvert aux modèles de plusieurs fournisseurs. Si vous construisez avec l’API Responses aujourd’hui, migrer vers Foundry ajoute la sécurité entreprise, le réseau privé, le RBAC Entra, le traçage complet et l’évaluation par-dessus votre logique d’agent existante.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Ajouts clés : réseau privé de bout en bout, extension de l’authentification MCP (y compris le passthrough OAuth), aperçu de Voice Live pour les agents voix-à-voix, et agents hébergés dans 6 nouvelles régions.

GPT-5.4 — la fiabilité plutôt que l’intelligence brute

GPT-5.4 n’est pas question d’être plus intelligent. C’est une question de fiabilité. Un raisonnement plus solide sur de longues interactions, une meilleure adhérence aux instructions, moins d’échecs en cours de workflow, et des capacités intégrées d’utilisation d’ordinateur. Pour les agents en production, cette fiabilité compte bien plus que les scores de benchmarks.

Modèle	Tarif (par M tokens)	Idéal pour
GPT-5.4 (≤272K)	$2.50 / $15 sortie	Agents en production, code, workflows documentaires
GPT-5.4 Pro	$30 / $180 sortie	Analyse approfondie, raisonnement scientifique
GPT-5.4 Mini	Économique	Classification, extraction, appels d’outils légers

La stratégie intelligente est le routage : GPT-5.4 Mini gère le travail à haut volume et faible latence tandis que GPT-5.4 prend les requêtes nécessitant un raisonnement intensif.

Le SDK est enfin stable

Le SDK azure-ai-projects a publié des versions stables dans tous les langages — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0, et .NET 2.0.0 (1er avril). La dépendance azure-ai-agents a disparu — tout vit sous AIProjectClient. Installez avec pip install azure-ai-projects et le paquet inclut openai et azure-identity comme dépendances directes.

Pour les développeurs .NET, cela signifie un seul paquet NuGet pour toute la surface Foundry. Fini le jonglage entre des SDKs d’agents séparés.

Fireworks AI amène les modèles ouverts sur Azure

Peut-être l’ajout le plus intéressant architecturalement : Fireworks AI traitant plus de 13 billions de tokens par jour à ~180K requêtes/seconde, maintenant disponible via Foundry. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, et MiniMax M2.5 au lancement.

La vraie histoire est le bring-your-own-weights — téléchargez des poids quantifiés ou fine-tunés depuis n’importe où sans changer la pile de service. Déployez en mode serverless pay-per-token ou en débit provisionné.

Autres points forts

Phi-4 Reasoning Vision 15B — raisonnement multimodal pour graphiques, diagrammes et mises en page de documents
Evaluations GA — évaluateurs prêts à l’emploi avec surveillance continue de production intégrée à Azure Monitor
Priority Processing (Preview) — voie de calcul dédiée pour les charges de travail sensibles à la latence
Voice Live — runtime voix-à-voix connecté directement aux agents Foundry
Tracing GA — inspection de bout en bout des traces d’agents avec tri et filtrage
Dépréciation de PromptFlow — migration vers Microsoft Framework Workflows d’ici janvier 2027

Conclusion

Mars 2026 est un tournant pour Foundry. Agent Service en GA, SDKs stables dans tous les langages, GPT-5.4 pour des agents de production fiables, et inférence de modèles ouverts via Fireworks AI — la plateforme est prête pour des charges de travail sérieuses.

Lisez le récapitulatif complet et créez votre premier agent pour commencer.

SQL MCP Server — La bonne façon de donner accès aux bases de données aux agents IA

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

Soyons honnêtes : la plupart des serveurs MCP de bases de données disponibles aujourd’hui sont effrayants. Ils prennent une requête en langage naturel, génèrent du SQL à la volée et l’exécutent contre vos données de production. Qu’est-ce qui pourrait mal tourner ? (Tout. Absolument tout.)

L’équipe Azure SQL vient de présenter SQL MCP Server, et il adopte une approche fondamentalement différente. Construit comme une fonctionnalité de Data API builder (DAB) 2.0, il donne aux agents IA un accès structuré et déterministe aux opérations de base de données — sans NL2SQL, sans exposer votre schéma, et avec un RBAC complet à chaque étape.

Pourquoi pas de NL2SQL ?

C’est la décision de conception la plus intéressante. Les modèles ne sont pas déterministes, et les requêtes complexes sont les plus susceptibles de produire des erreurs subtiles. Les requêtes exactes que les utilisateurs espèrent que l’IA peut générer sont aussi celles qui nécessitent le plus de vérification quand elles sont produites de manière non déterministe.

À la place, SQL MCP Server utilise une approche NL2DAB. L’agent travaille avec la couche d’abstraction d’entités de Data API builder et son constructeur de requêtes intégré pour produire du T-SQL précis et bien formé de manière déterministe. Même résultat pour l’utilisateur, mais sans le risque de JOINs hallucinés ou d’exposition accidentelle de données.

Sept outils, pas sept cents

SQL MCP Server expose exactement sept outils DML, quelle que soit la taille de la base de données :

describe_entities — découvrir les entités et opérations disponibles
create_record — insérer des lignes
read_records — interroger des tables et vues
update_record — modifier des lignes
delete_record — supprimer des lignes
execute_entity — exécuter des procédures stockées
aggregate_records — requêtes d’agrégation

C’est malin, car les fenêtres de contexte sont l’espace de réflexion de l’agent. Les inonder de centaines de définitions d’outils laisse moins de place au raisonnement. Sept outils fixes gardent l’agent concentré sur la réflexion plutôt que la navigation.

Chaque outil peut être activé ou désactivé individuellement :

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Démarrage en trois commandes

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Voilà un SQL MCP Server en fonctionnement qui expose votre table Customers. La couche d’abstraction d’entités vous permet de créer des alias pour les noms et colonnes, de limiter les champs par rôle et de contrôler exactement ce que les agents voient — sans exposer les détails internes du schéma.

L’aspect sécurité est solide

C’est là que la maturité de Data API builder porte ses fruits :

RBAC à chaque couche — chaque entité définit quels rôles peuvent lire, créer, mettre à jour ou supprimer, et quels champs sont visibles
Intégration Azure Key Vault — chaînes de connexion et secrets gérés de manière sécurisée
Microsoft Entra + OAuth personnalisé — authentification de niveau production
Content Security Policy — les agents interagissent via un contrat contrôlé, pas du SQL brut

L’abstraction du schéma est particulièrement importante. Vos noms internes de tables et colonnes ne sont jamais exposés à l’agent. Vous définissez des entités, des alias et des descriptions qui ont du sens pour l’interaction IA — pas votre diagramme ERD de base de données.

Multi-bases et multi-protocoles

SQL MCP Server supporte Microsoft SQL, PostgreSQL, Azure Cosmos DB et MySQL. Et comme c’est une fonctionnalité de DAB, vous obtenez des endpoints REST, GraphQL et MCP simultanément depuis la même configuration. Mêmes définitions d’entités, mêmes règles RBAC, même sécurité — sur les trois protocoles.

L’auto-configuration dans DAB 2.0 peut même inspecter votre base de données et construire la configuration dynamiquement, si vous êtes à l’aise avec moins d’abstraction pour du prototypage rapide.

Mon avis

C’est ainsi que l’accès base de données d’entreprise pour les agents IA devrait fonctionner. Pas « hey LLM, écris-moi du SQL et YOLO sur la prod ». À la place : une couche d’entités bien définie, une génération de requêtes déterministe, RBAC à chaque étape, cache, monitoring et télémétrie. C’est ennuyeux de la meilleure façon possible.

Pour les développeurs .NET, l’histoire d’intégration est propre — DAB est un outil .NET, le MCP Server tourne en conteneur, et il fonctionne avec Azure SQL, que la plupart d’entre nous utilisent déjà. Si vous construisez des agents IA qui ont besoin d’accéder aux données, commencez ici.

Pour conclure

SQL MCP Server est gratuit, open-source et tourne partout. C’est l’approche prescriptive de Microsoft pour donner aux agents IA un accès sécurisé aux bases de données. Consultez le post complet et la documentation pour commencer.

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.

C# 15 intègre les types union — et c'est exactement ce qu'on demandait

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

C’est celle que j’attendais. C# 15 introduit le mot-clé union — de vraies unions discriminées avec du pattern matching exhaustif imposé par le compilateur. Si vous avez déjà envié les unions discriminées de F# ou les enums de Rust, vous savez exactement pourquoi c’est important.

Bill Wagner a publié l’analyse approfondie sur le blog .NET, et franchement ? Le design est propre, pratique et très C#. Laissez-moi vous montrer ce qu’il y a vraiment et pourquoi c’est plus important qu’il n’y paraît à première vue.

Le problème que les unions résolvent

Avant C# 15, retourner “l’un des plusieurs types possibles” depuis une méthode était toujours un compromis :

object — pas de contraintes, pas d’aide du compilateur, du casting défensif partout
Interfaces marqueurs — mieux, mais n’importe qui peut les implémenter. Le compilateur ne peut jamais considérer l’ensemble comme complet
Classes de base abstraites — même problème, en plus les types ont besoin d’un ancêtre commun

Aucune de ces solutions ne vous donne ce que vous voulez vraiment : un ensemble fermé de types où le compilateur garantit que vous avez géré chaque cas. C’est ce que font les types union.

La syntaxe est d’une simplicité élégante

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

Une ligne. Pet peut contenir un Cat, un Dog ou un Bird. Les conversions implicites sont générées automatiquement :

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

Et voici la magie — le compilateur impose le matching exhaustif :

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

Pas besoin de discard _. Le compilateur sait que ce switch couvre tous les cas possibles. Si vous ajoutez plus tard un quatrième type à l’union, chaque expression switch qui ne le gère pas produit un avertissement. Les cas manquants détectés au moment de la compilation, pas à l’exécution.

Là où ça devient pratique

L’exemple de Pet est mignon, mais c’est ici que les unions brillent vraiment dans du vrai code.

Des réponses API qui retournent différentes formes

public union ApiResult<T>(T, ApiError, ValidationFailure);

Maintenant chaque consommateur est obligé de gérer le succès, l’erreur et l’échec de validation. Plus de bugs “j’ai oublié de vérifier le cas d’erreur”.

Valeur unique ou collection

Le pattern OneOrMore<T> montre comment les unions peuvent avoir un corps avec des méthodes utilitaires :

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

Les appelants passent la forme qui leur convient :

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

Composer des types sans relation

C’est la fonctionnalité décisive par rapport aux hiérarchies traditionnelles. Vous pouvez unir des types qui n’ont rien en commun — string et Exception, int et IEnumerable<T>. Pas besoin d’ancêtre commun.

Unions personnalisées pour les bibliothèques existantes

Voici un choix de design intelligent : toute classe ou struct avec un attribut [Union] est reconnue comme un type union, tant qu’elle suit le pattern de base (constructeurs publics pour les types de cas et une propriété Value). Les bibliothèques comme OneOf qui fournissent déjà des types similaires aux unions peuvent opter pour le support du compilateur sans réécrire leurs internals.

Pour les scénarios sensibles à la performance avec des types valeur, les bibliothèques peuvent implémenter un pattern d’accès sans boxing avec les méthodes HasValue et TryGetValue.

La vision d’ensemble

Les types union font partie d’une histoire plus large d’exhaustivité qui arrive en C# :

Types union — matching exhaustif sur un ensemble fermé de types (disponible maintenant en preview)
Hiérarchies fermées — le modificateur closed empêche les classes dérivées en dehors de l’assembly de définition (proposé)
Enums fermés — empêche la création de valeurs autres que les membres déclarés (proposé)

Ensemble, ces trois fonctionnalités donneront à C# l’un des systèmes de pattern matching typé les plus complets de tous les langages mainstream.

Essayez-les aujourd’hui

Les types union sont disponibles dans .NET 11 Preview 2 :

Installez le SDK .NET 11 Preview
Ciblez net11.0 dans votre projet
Définissez <LangVersion>preview</LangVersion>

Une mise en garde : dans Preview 2, vous devrez déclarer UnionAttribute et IUnion dans votre projet car ils ne sont pas encore dans le runtime. Récupérez RuntimePolyfill.cs depuis le repo docs, ou ajoutez ceci :

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

Pour conclure

Les types union sont une de ces fonctionnalités qui vous font vous demander comment on a pu s’en passer. Du matching exhaustif imposé par le compilateur, une syntaxe propre, le support des génériques et l’intégration avec le pattern matching existant — c’est tout ce qu’on demandait, fait à la manière C#.

Essayez-les dans .NET 11 Preview 2, cassez des trucs et partagez vos retours sur GitHub. C’est une preview, et l’équipe C# écoute activement. Vos cas limites et retours de design façonneront la version finale.

Pour la référence complète du langage, consultez la documentation des types union et la spécification de la fonctionnalité.

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.

Microsoft Agent Framework Atteint la 1.0 — Voici Ce Qui Compte Vraiment pour les Développeurs .NET

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

Si vous avez suivi le parcours d’Agent Framework depuis les premiers jours de Semantic Kernel et AutoGen, celui-ci est significatif. Microsoft Agent Framework vient d’atteindre la version 1.0 — prêt pour la production, APIs stables, engagement de support à long terme. Il est disponible pour .NET et Python, et il est véritablement prêt pour les charges de travail réelles.

Laissez-moi couper à travers le bruit de l’annonce et me concentrer sur ce qui compte si vous construisez des applications alimentées par l’IA avec .NET.

La version courte

Agent Framework 1.0 unifie ce qui était auparavant Semantic Kernel et AutoGen en un seul SDK open source. Une abstraction d’agent. Un moteur d’orchestration. Plusieurs fournisseurs d’IA. Si vous avez jonglé entre Semantic Kernel pour les patterns entreprise et AutoGen pour les workflows multi-agent de niveau recherche, vous pouvez arrêter. C’est le seul SDK maintenant.

Démarrer est presque injustement simple

Voici un agent fonctionnel en .NET :

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

C’est tout. Une poignée de lignes et vous avez un agent IA qui tourne contre Azure Foundry. L’équivalent Python est tout aussi concis. Ajoutez des outils de fonctions, des conversations multi-tours et du streaming au fur et à mesure — la surface de l’API monte en puissance sans devenir bizarre.

Orchestration multi-agent — c’est du sérieux

Les agents individuels sont bien pour les démos, mais les scénarios de production nécessitent généralement de la coordination. Agent Framework 1.0 est livré avec des patterns d’orchestration éprouvés au combat directement de Microsoft Research et AutoGen :

Séquentiel — les agents traitent dans l’ordre (rédacteur → réviseur → éditeur)
Concurrent — distribue vers plusieurs agents en parallèle, converge les résultats
Handoff — un agent délègue à un autre basé sur l’intention
Chat de groupe — plusieurs agents discutent et convergent vers une solution
Magentic-One — le pattern multi-agent de niveau recherche de MSR

Tous supportent le streaming, le checkpointing, les approbations humain-dans-la-boucle, et la pause/reprise. La partie checkpointing est cruciale — les workflows de longue durée survivent aux redémarrages de processus. Pour nous, développeurs .NET qui avons construit des workflows durables avec Azure Functions, ça nous parle.

Les fonctionnalités qui comptent le plus

Voici ma liste de ce qui vaut la peine d’être connu :

Hooks middleware. Vous savez comment ASP.NET Core a des pipelines middleware ? Même concept, mais pour l’exécution des agents. Interceptez chaque étape — ajoutez la sécurité du contenu, le logging, les politiques de conformité — sans toucher aux prompts de l’agent. C’est comme ça que vous rendez les agents prêts pour l’entreprise.

Mémoire pluggable. Historique conversationnel, état persistant clé-valeur, récupération basée sur les vecteurs. Choisissez votre backend : Foundry Agent Service, Mem0, Redis, Neo4j, ou créez le vôtre. La mémoire est ce qui transforme un appel LLM sans état en un agent qui se souvient réellement du contexte.

Agents YAML déclaratifs. Définissez les instructions de votre agent, ses outils, sa mémoire et sa topologie d’orchestration dans des fichiers YAML versionnés. Chargez et exécutez avec un seul appel API. C’est un changement de donne pour les équipes qui veulent itérer sur le comportement de l’agent sans redéployer du code.

Support A2A et MCP. MCP (Model Context Protocol) permet aux agents de découvrir et d’invoquer des outils externes dynamiquement. A2A (protocole Agent-to-Agent) permet la collaboration inter-runtime — vos agents .NET peuvent se coordonner avec des agents s’exécutant dans d’autres frameworks. Le support A2A 1.0 arrive bientôt.

Les fonctionnalités en preview à surveiller

Certaines fonctionnalités ont été livrées en preview dans la 1.0 — fonctionnelles mais les APIs peuvent évoluer :

DevUI — un débogueur local basé navigateur pour visualiser l’exécution de l’agent, les flux de messages et les appels d’outils en temps réel. Pensez Application Insights, mais pour le raisonnement de l’agent.
GitHub Copilot SDK et Claude Code SDK — utilisez Copilot ou Claude comme harness d’agent directement depuis votre code d’orchestration. Composez un agent capable de coder aux côtés de vos autres agents dans le même workflow.
Agent Harness — un runtime local personnalisable donnant aux agents l’accès au shell, au système de fichiers et aux boucles de messagerie. Pensez agents de codage et patterns d’automatisation.
Skills — des packages de capacités de domaine réutilisables qui donnent aux agents des capacités structurées prêtes à l’emploi.

Migration depuis Semantic Kernel ou AutoGen

Si vous avez du code Semantic Kernel ou AutoGen existant, il existe des assistants de migration dédiés qui analysent votre code et génèrent des plans de migration étape par étape. Le guide de migration Semantic Kernel et le guide de migration AutoGen vous accompagnent à travers tout.

Si vous étiez sur les packages RC, la mise à niveau vers 1.0 est juste un changement de version.

Pour conclure

Agent Framework 1.0 est le jalon de production que les équipes entreprise attendaient. APIs stables, support multi-fournisseur, patterns d’orchestration qui fonctionnent réellement à l’échelle, et des chemins de migration depuis Semantic Kernel et AutoGen.

Le framework est entièrement open source sur GitHub, et vous pouvez commencer dès aujourd’hui avec dotnet add package Microsoft.Agents.AI. Consultez le guide de démarrage rapide et les exemples pour mettre les mains dans le cambouis.

Si vous attendiez le signal « utilisable en production en toute sécurité » — c’est celui-ci.

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.

Le Dashboard d'Aspire 13.2 a maintenant une API de télémétrie — et ça change tout

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

Si vous développez des applications distribuées avec .NET Aspire, vous savez déjà que le dashboard est la meilleure chose de toute l’expérience. Toutes vos traces, logs et métriques au même endroit — pas de Jaeger externe, pas de configuration Seq, pas de moments « laissez-moi vérifier l’autre terminal ».

Aspire 13.2 vient de considérablement améliorer les choses. James Newton-King a annoncé la mise à jour, et honnêtement ? Les fonctionnalités d’export de télémétrie et l’API justifient à elles seules la mise à niveau.

Exporter la télémétrie comme une personne normale

Voici le scénario qu’on a tous vécu : vous déboguez un problème distribué, vous le reproduisez enfin après vingt minutes de configuration, et maintenant vous devez partager ce qui s’est passé avec votre équipe. Avant ? Des captures d’écran. Du copier-coller d’identifiants de traces. Le bazar habituel.

Aspire 13.2 ajoute un dialogue Gérer les logs et la télémétrie où vous pouvez :

Effacer toute la télémétrie (utile avant une tentative de reproduction)
Exporter la télémétrie sélectionnée dans un fichier ZIP au format standard OTLP/JSON
Ré-importer ce ZIP dans n’importe quel dashboard Aspire ultérieurement

Ce dernier point est la fonctionnalité phare. Vous reproduisez un bug, exportez la télémétrie, l’attachez à votre work item, et votre collègue peut l’importer dans son propre dashboard pour voir exactement ce que vous avez vu. Fini le « tu peux reproduire sur ta machine ? »

Les traces, spans et logs individuels ont aussi une option « Export JSON » dans leurs menus contextuels. Besoin de partager une trace spécifique ? Clic droit, copier le JSON, coller dans la description de votre PR. Terminé.

L’API de télémétrie est le vrai changement majeur

C’est ce qui m’enthousiasme le plus. Le dashboard expose maintenant une API HTTP sous /api/telemetry pour interroger les données de télémétrie programmatiquement. Endpoints disponibles :

GET /api/telemetry/resources — lister les ressources avec télémétrie
GET /api/telemetry/spans — interroger les spans avec des filtres
GET /api/telemetry/logs — interroger les logs avec des filtres
GET /api/telemetry/traces — lister les traces
GET /api/telemetry/traces/{traceId} — obtenir tous les spans d’une trace spécifique

Tout revient au format OTLP JSON. Cela alimente les nouvelles commandes CLI aspire agent mcp et aspire otel, mais l’implication réelle est plus grande : vous pouvez maintenant construire des outils, scripts et intégrations d’agents IA qui interrogent directement la télémétrie de votre app.

Imaginez un agent IA de codage qui peut voir vos traces distribuées réelles pendant le débogage. Ce n’est plus hypothétique — c’est ce que cette API permet.

La télémétrie GenAI devient pratique

Si vous construisez des apps alimentées par l’IA avec Semantic Kernel ou Microsoft.Extensions.AI, vous apprécierez le visualiseur de télémétrie GenAI amélioré. Aspire 13.2 ajoute :

Les descriptions d’outils IA rendues en Markdown
Un bouton GenAI dédié sur la page des traces pour un accès rapide
Une meilleure gestion des erreurs pour le JSON GenAI tronqué ou non standard
Une navigation click-to-highlight entre les définitions d’outils

L’article mentionne que VS Code Copilot chat, Copilot CLI et OpenCode supportent tous la configuration d’un OTEL_EXPORTER_OTLP_ENDPOINT. Pointez-les vers le dashboard Aspire et vous pouvez littéralement regarder vos agents IA réfléchir en temps réel via la télémétrie. C’est une expérience de débogage que vous ne trouverez nulle part ailleurs.

Pour conclure

Aspire 13.2 transforme le dashboard d’une « jolie UI de débogage » en « plateforme d’observabilité programmable ». Le workflow d’export/import seul fait gagner du temps réel en débogage distribué, et l’API de télémétrie ouvre la porte au diagnostic assisté par IA.

Si vous êtes déjà sur Aspire, mettez à jour. Sinon — c’est une bonne raison de découvrir aspire.dev.

KubeCon Europe 2026 : Ce que les développeurs .NET devraient vraiment retenir

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

Vous connaissez cette sensation quand un énorme post d’annonces tombe et que vous scrollez en pensant « cool, mais concrètement ça change quoi pour moi » ? C’est moi à chaque saison KubeCon.

Microsoft vient de publier son récapitulatif complet de KubeCon Europe 2026 — écrit par Brendan Burns en personne — et honnêtement ? Il y a du vrai contenu ici. Pas juste des cases à cocher, mais des améliorations opérationnelles qui changent votre façon de gérer les choses en production.

Laissez-moi décortiquer ce qui compte vraiment pour nous développeurs .NET.

mTLS sans la taxe du service mesh

Voici le truc avec les service meshes : tout le monde veut les garanties de sécurité, personne ne veut la charge opérationnelle. AKS comble enfin cet écart.

Azure Kubernetes Application Network vous donne le TLS mutuel, l’autorisation consciente de l’application et la télémétrie du trafic — sans déployer un mesh complet avec sidecars. Combiné avec Cilium mTLS dans Advanced Container Networking Services, vous obtenez une communication chiffrée pod-à-pod utilisant des certificats X.509 et SPIRE pour la gestion des identités.

Ce que ça signifie en pratique : vos APIs ASP.NET Core qui communiquent avec des workers en arrière-plan, vos services gRPC qui s’appellent mutuellement — tout chiffré et vérifié au niveau réseau, sans aucune modification de code. C’est énorme.

Pour les équipes qui migrent depuis ingress-nginx, il y a aussi Application Routing avec Meshless Istio avec support complet de Kubernetes Gateway API. Pas de sidecars. Basé sur les standards. Et ils ont livré des outils ingress2gateway pour une migration incrémentale.

Observabilité GPU qui n’est pas une pensée après coup

Si vous exécutez de l’inférence IA aux côtés de vos services .NET (et soyons honnêtes, qui ne commence pas ?), vous avez probablement rencontré l’angle mort du monitoring GPU. Vous aviez de super dashboards CPU/mémoire et ensuite… rien pour les GPU sans configuration manuelle d’exporteurs.

AKS expose maintenant les métriques GPU nativement dans Prometheus et Grafana managés. Même stack, mêmes dashboards, même pipeline d’alertes. Pas d’exporteurs custom, pas d’agents tiers.

Côté réseau, ils ont ajouté de la visibilité par flux pour le trafic HTTP, gRPC et Kafka avec une expérience Azure Monitor en un clic. IPs, ports, workloads, direction des flux, décisions de policies — tout dans des dashboards intégrés.

Et voici celle qui m’a fait regarder deux fois : agentic container networking ajoute une interface web où vous pouvez poser des questions en langage naturel sur l’état réseau de votre cluster. « Pourquoi le pod X n’atteint-il pas le service Y ? » → diagnostics en lecture seule depuis la télémétrie en direct. C’est vraiment utile à 2h du matin.

Networking cross-cluster sans avoir besoin d’un doctorat

Le multi-cluster Kubernetes a toujours été une expérience « apportez votre propre colle réseau ». Azure Kubernetes Fleet Manager propose maintenant du networking cross-cluster via un cluster mesh Cilium managé :

Connectivité unifiée entre clusters AKS
Registre global de services pour la découverte cross-cluster
Configuration gérée centralement, pas répétée par cluster

Si vous exécutez des microservices .NET sur plusieurs régions pour la résilience ou la conformité, ça remplace beaucoup de colle custom fragile. Le Service A en West Europe peut découvrir et appeler le Service B en East US à travers le mesh, avec des politiques de routage et de sécurité cohérentes.

Des mises à jour qui ne demandent pas du courage

Soyons honnêtes — les mises à jour Kubernetes en production sont stressantes. « Mettre à jour et espérer » a été la stratégie de fait pour trop d’équipes, et c’est la raison principale pour laquelle les clusters restent en retard sur les versions.

Deux nouvelles capacités changent la donne :

Les blue-green agent pool upgrades créent un pool de nœuds parallèle avec la nouvelle configuration. Validez le comportement, déplacez le trafic progressivement et gardez un chemin de rollback propre. Plus de mutations in-place sur les nœuds de production.

Le rollback d’agent pool permet de revenir à la version Kubernetes et l’image de nœud précédentes d’un pool après qu’une mise à jour se passe mal — sans reconstruire le cluster.

Ensemble, ils donnent enfin aux opérateurs un vrai contrôle sur le cycle de vie des mises à jour. Pour les équipes .NET, c’est important car la vélocité de la plateforme contrôle directement la vitesse à laquelle vous pouvez adopter de nouveaux runtimes, patchs de sécurité et capacités réseau.

Les workloads IA deviennent des citoyens de première classe Kubernetes

Le travail upstream en open-source est tout aussi important. Dynamic Resource Allocation (DRA) vient de passer en GA dans Kubernetes 1.36, faisant du scheduling GPU une vraie fonctionnalité de première classe plutôt qu’un contournement.

Quelques projets à surveiller :

Projet	Ce qu’il fait
AI Runway	API Kubernetes commune pour l’inférence — déployez des modèles sans connaître K8s, avec découverte HuggingFace et estimations de coûts
HolmesGPT	Dépannage agentique pour le cloud-native — maintenant un projet CNCF Sandbox
Dalec	Builds déclaratifs d’images de conteneur avec génération de SBOM — moins de CVE à l’étape de build

La direction est claire : votre API .NET, votre couche d’orchestration Semantic Kernel et vos workloads d’inférence devraient tous tourner sur un modèle de plateforme cohérent. On y arrive.

Par où commencer cette semaine

Si vous évaluez ces changements pour votre équipe, voici ma liste de priorités honnête :

L’observabilité d’abord — activez les métriques GPU et les logs de flux réseau dans un cluster non-prod. Voyez ce que vous avez manqué.
Testez les blue-green upgrades — essayez le workflow de rollback avant votre prochaine mise à jour de cluster en production. Construisez la confiance dans le processus.
Pilotez le networking identity-aware — choisissez un chemin de service interne et activez mTLS avec Cilium. Mesurez l’overhead (spoiler : c’est minimal).
Évaluez Fleet Manager — si vous gérez plus de deux clusters, le networking cross-cluster se rentabilise tout seul en réduisant la colle custom.

Petites expériences, feedback rapide. C’est toujours le bon choix.

Pour conclure

Les annonces KubeCon peuvent être accablantes, mais cette fournée fait vraiment bouger les choses pour les équipes .NET sur AKS. Meilleure sécurité réseau sans overhead de mesh, vraie observabilité GPU, mises à jour plus sûres et des fondations d’infrastructure IA plus solides.

Si vous êtes déjà sur AKS, c’est un excellent moment pour renforcer votre baseline opérationnel. Et si vous prévoyez de migrer des workloads .NET vers Kubernetes — la plateforme vient de devenir nettement plus prête pour la production.

SQL MCP Server, Copilot dans SSMS et un Database Hub avec des agents IA : Ce qui compte vraiment de SQLCon 2026

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft vient de lancer SQLCon 2026 en parallèle de FabCon à Atlanta, et il y a beaucoup à décortiquer. L’annonce originale couvre tout, des plans d’économies aux fonctionnalités de conformité enterprise. Je vais passer les slides sur les tarifs enterprise et me concentrer sur les éléments qui comptent si vous êtes un développeur qui construit des choses avec Azure SQL et l’IA.

SQL MCP Server est en public preview

C’est le titre principal pour moi. Azure SQL Database Hyperscale dispose maintenant d’un SQL MCP Server en public preview qui vous permet de connecter vos données SQL de manière sécurisée à des agents IA et des Copilots en utilisant le Model Context Protocol.

Si vous avez suivi la vague MCP — et honnêtement, c’est difficile de la rater en ce moment — c’est une grosse nouvelle. Au lieu de construire des pipelines de données personnalisés pour alimenter vos agents IA en contexte depuis votre base de données, vous obtenez un protocole standardisé pour exposer les données SQL directement. Vos agents peuvent interroger, raisonner et agir sur des informations de base de données en temps réel.

Pour ceux d’entre nous qui construisent des agents IA avec Semantic Kernel ou le Microsoft Agent Framework, ça ouvre un chemin d’intégration propre. Votre agent a besoin de vérifier l’inventaire ? Chercher un enregistrement client ? Valider une commande ? MCP lui donne une façon structurée de le faire sans que vous écriviez du code de récupération de données sur mesure pour chaque scénario.

GitHub Copilot dans SSMS 22 est maintenant GA

Si vous passez du temps dans SQL Server Management Studio — et soyons honnêtes, la plupart d’entre nous le font encore — GitHub Copilot est maintenant disponible de manière générale dans SSMS 22. La même expérience Copilot que vous utilisez déjà dans VS Code et Visual Studio, mais pour T-SQL.

La valeur pratique est simple : une assistance par chat pour écrire des requêtes, refactoriser des procédures stockées, résoudre des problèmes de performance et gérer des tâches d’administration. Rien de révolutionnaire dans le concept, mais l’avoir directement dans SSMS signifie que vous n’avez pas besoin de changer de contexte vers un autre éditeur juste pour obtenir de l’aide IA sur votre travail de base de données.

Les index vectoriels ont reçu une sérieuse mise à jour

Azure SQL Database dispose maintenant d’index vectoriels plus rapides et plus performants avec un support complet pour l’insertion, la mise à jour et la suppression. Ça veut dire que vos données vectorielles restent à jour en temps réel — pas besoin de réindexation par lots.

Voici les nouveautés :

Quantification pour des tailles d’index plus petites sans trop perdre en précision
Filtrage itératif pour des résultats plus précis
Intégration plus étroite avec l’optimiseur de requêtes pour des performances prévisibles

Si vous faites du Retrieval-Augmented Generation (RAG) avec Azure SQL comme vector store, ces améliorations sont directement utiles. Vous pouvez garder vos vecteurs à côté de vos données relationnelles dans la même base de données, ce qui simplifie considérablement votre architecture par rapport à l’exécution d’une base de données vectorielle séparée.

Les mêmes améliorations vectorielles sont également disponibles dans SQL Database in Fabric, puisque les deux tournent sur le même moteur SQL en dessous.

Database Hub dans Fabric : gestion agentique

Celui-ci est plus tourné vers l’avenir, mais il est intéressant. Microsoft a annoncé le Database Hub dans Microsoft Fabric (accès anticipé), qui vous donne une vue unifiée sur Azure SQL, Cosmos DB, PostgreSQL, MySQL et SQL Server via Arc.

L’angle intéressant n’est pas juste la vue unifiée — c’est l’approche agentique de la gestion. Des agents IA surveillent en continu votre parc de bases de données, font remonter ce qui a changé, expliquent pourquoi c’est important et suggèrent quoi faire ensuite. C’est un modèle human-in-the-loop où l’agent fait le gros du travail et vous prenez les décisions.

Pour les équipes qui gèrent plus qu’une poignée de bases de données, ça pourrait vraiment réduire le bruit opérationnel. Au lieu de sauter entre les portails et de vérifier manuellement les métriques, l’agent vous apporte le signal.

Ce que ça signifie pour les développeurs .NET

Le fil conducteur de toutes ces annonces est clair : Microsoft intègre des agents IA à chaque couche de la pile de bases de données. Pas comme un gadget, mais comme une couche d’outillage pratique.

Si vous construisez des apps .NET adossées à Azure SQL, voici ce que je ferais concrètement :

Essayez le SQL MCP Server si vous construisez des agents IA. C’est la façon la plus propre de donner à vos agents un accès à la base de données sans plomberie personnalisée.
Activez Copilot dans SSMS si ce n’est pas déjà fait — un gain de productivité gratuit pour le travail SQL quotidien.
Regardez les index vectoriels si vous faites du RAG et que vous utilisez actuellement un vector store séparé. Consolider sur Azure SQL signifie un service de moins à gérer.

Pour conclure

L’annonce complète contient plus — plans d’économies, assistants de migration, fonctionnalités de conformité — mais l’histoire pour les développeurs se trouve dans le MCP Server, les améliorations vectorielles et la couche de gestion agentique. Ce sont les éléments qui changent la façon dont vous construisez, pas juste la façon dont vous budgétisez.

Consultez l’annonce complète de Shireesh Thota pour avoir le tableau complet, et inscrivez-vous pour l’accès anticipé au Database Hub si vous voulez essayer la nouvelle expérience de gestion.

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.

Foundry Agent Service est GA : Ce qui compte vraiment pour les développeurs d'agents .NET

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

Soyons honnêtes — construire un prototype d’agent IA est la partie facile. La partie difficile, c’est tout ce qui suit : le mettre en production avec un isolement réseau approprié, exécuter des évaluations qui signifient réellement quelque chose, gérer les exigences de conformité, et ne rien casser à 2h du matin.

Le Foundry Agent Service vient de passer en GA, et cette version est focalisée comme un laser sur ce fossé du “tout ce qui suit”.

Construit sur la Responses API

Le titre principal : le Foundry Agent Service de nouvelle génération est construit sur l’OpenAI Responses API. Si vous construisez déjà avec ce protocole, migrer vers Foundry nécessite des changements de code minimaux. Ce que vous gagnez : sécurité entreprise, réseau privé, RBAC Entra, traçabilité complète et évaluation — par-dessus votre logique d’agent existante.

L’architecture est intentionnellement ouverte. Vous n’êtes pas verrouillé à un fournisseur de modèle ou un framework d’orchestration. Utilisez DeepSeek pour la planification, OpenAI pour la génération, LangGraph pour l’orchestration — le runtime gère la couche de cohérence.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Réseau privé : le bloqueur entreprise supprimé

C’est la fonctionnalité qui débloque l’adoption enterprise. Foundry supporte maintenant le réseau privé complet de bout en bout avec BYO VNet :

Aucun egress public — le trafic de l’agent ne touche jamais l’internet public
Injection de conteneurs/sous-réseaux dans votre réseau pour la communication locale
Connectivité des outils incluse — serveurs MCP, Azure AI Search, agents de données Fabric fonctionnent tous sur des chemins privés

Ce dernier point est critique. Ce ne sont pas seulement les appels d’inférence qui restent privés — chaque invocation d’outil et appel de récupération reste aussi à l’intérieur de votre périmètre réseau. Pour les équipes opérant sous des politiques de classification de données qui interdisent le routage externe, c’est ce qui manquait.

Authentification MCP bien faite

Les connexions aux serveurs MCP supportent maintenant le spectre complet des patterns d’authentification :

Méthode d’auth	Quand l’utiliser
Basée sur clé	Accès partagé simple pour les outils internes à l’organisation
Entra Agent Identity	Service à service ; l’agent s’authentifie comme lui-même
Entra Managed Identity	Isolation par projet ; pas de gestion de credentials
OAuth Identity Passthrough	Accès délégué par utilisateur ; l’agent agit au nom des utilisateurs

OAuth Identity Passthrough est le plus intéressant. Quand les utilisateurs doivent donner à un agent l’accès à leurs données personnelles — leur OneDrive, leur organisation Salesforce, une API SaaS scopée par utilisateur — l’agent agit en leur nom avec des flux OAuth standard. Pas d’identité système partagée prétendant être tout le monde.

Voice Live : voix à voix sans la plomberie

Ajouter la voix à un agent signifiait auparavant assembler STT, LLM et TTS — trois services, trois sauts de latence, trois surfaces de facturation, le tout synchronisé à la main. Voice Live condense tout ça en une seule API managée avec :

Détection sémantique de l’activité vocale et de fin de tour (comprend le sens, pas juste le silence)
Suppression du bruit et annulation d’écho côté serveur
Support du barge-in (les utilisateurs peuvent interrompre en pleine réponse)

Les interactions vocales passent par le même runtime d’agent que le texte. Mêmes évaluateurs, mêmes traces, même visibilité des coûts. Pour le support client, le service terrain ou les scénarios d’accessibilité, ça remplace ce qui nécessitait auparavant un pipeline audio personnalisé.

Évaluations : de la case à cocher au monitoring continu

C’est là que Foundry devient sérieux sur la qualité en production. Le système d’évaluation a maintenant trois couches :

Évaluateurs prêts à l’emploi — cohérence, pertinence, fondement, qualité de récupération, sécurité. Connectez à un dataset ou au trafic en direct et obtenez des scores.
Évaluateurs personnalisés — encodez votre propre logique métier, standards de ton et règles de conformité spécifiques au domaine.
Évaluation continue — Foundry échantillonne le trafic de production en direct, exécute votre suite d’évaluateurs et affiche les résultats dans des tableaux de bord. Configurez des alertes Azure Monitor pour quand le fondement baisse ou que les seuils de sécurité sont dépassés.

Tout est publié dans Azure Monitor Application Insights. Qualité de l’agent, santé de l’infrastructure, coûts et télémétrie applicative — tout au même endroit.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Six nouvelles régions pour les agents hébergés

Les agents hébergés sont maintenant disponibles dans East US, North Central US, Sweden Central, Southeast Asia, Japan East et plus. C’est important pour les exigences de résidence des données et pour comprimer la latence quand votre agent tourne près de ses sources de données.

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

Même si les exemples de code dans l’annonce GA sont Python-first, l’infrastructure sous-jacente est agnostique au langage — et le SDK .NET pour azure-ai-projects suit les mêmes patterns. La Responses API, le framework d’évaluation, le réseau privé, l’auth MCP — tout cela est disponible depuis .NET.

Si vous attendiez que les agents IA passent de “démo cool” à “je peux réellement livrer ça au travail”, cette version GA est le signal. Réseau privé, authentification appropriée, évaluation continue et monitoring de production sont les pièces qui manquaient.

Pour conclure

Foundry Agent Service est disponible maintenant. Installez le SDK, ouvrez le portail et commencez à construire. Le guide de démarrage rapide vous amène de zéro à un agent en fonctionnement en quelques minutes.

Pour le deep-dive technique complet avec tous les exemples de code, consultez l’annonce GA.

Le serveur MCP Azure DevOps débarque dans Microsoft Foundry : ce que ça signifie pour vos agents IA

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

MCP (Model Context Protocol) a le vent en poupe. Si vous suivez l’écosystème des agents IA, vous avez probablement remarqué que les serveurs MCP apparaissent partout — donnant aux agents la capacité d’interagir avec des outils et services externes via un protocole standardisé.

Maintenant le serveur MCP Azure DevOps est disponible dans Microsoft Foundry, et c’est une de ces intégrations qui fait réfléchir aux possibilités pratiques.

Ce qui se passe réellement ici

Microsoft a déjà publié le serveur MCP Azure DevOps en public preview — c’est le serveur MCP lui-même. La nouveauté, c’est l’intégration Foundry. Vous pouvez maintenant ajouter le serveur MCP Azure DevOps à vos agents Foundry directement depuis le catalogue d’outils.

Pour ceux qui ne connaissent pas encore Foundry : c’est la plateforme unifiée de Microsoft pour construire et gérer des applications et agents alimentés par l’IA à grande échelle. Accès aux modèles, orchestration, évaluation, déploiement — tout au même endroit.

La mise en place

La configuration est étonnamment simple :

Dans votre agent Foundry, allez dans Add Tools > Catalog
Cherchez “Azure DevOps”
Sélectionnez le Azure DevOps MCP Server (preview) et cliquez sur Create
Entrez le nom de votre organisation et connectez

C’est tout. Votre agent a maintenant accès aux outils Azure DevOps.

Contrôler ce à quoi votre agent peut accéder

C’est la partie que j’apprécie : vous n’êtes pas coincé avec une approche tout-ou-rien. Vous pouvez spécifier quels outils sont disponibles pour votre agent. Si vous voulez qu’il ne lise que les work items sans toucher aux pipelines, vous pouvez configurer ça. Principe du moindre privilège, appliqué à vos agents IA.

C’est important pour les scénarios enterprise où vous ne voulez pas qu’un agent déclenche accidentellement un pipeline de déploiement parce que quelqu’un lui a demandé d’“aider avec la release.”

Pourquoi c’est intéressant pour les équipes .NET

Pensez à ce que ça permet en pratique :

Assistants de planification de sprint — des agents qui peuvent récupérer les work items, analyser les données de vélocité et suggérer la capacité du sprint
Bots de code review — des agents qui comprennent le contexte de votre PR parce qu’ils peuvent réellement lire vos repos et work items liés
Réponse aux incidents — des agents qui peuvent créer des work items, interroger les déploiements récents et corréler les bugs avec les changements récents
Onboarding des développeurs — “Sur quoi devrais-je travailler ?” obtient une vraie réponse basée sur les données réelles du projet

Pour les équipes .NET qui utilisent déjà Azure DevOps pour leurs pipelines CI/CD et la gestion de projet, avoir un agent IA qui peut interagir directement avec ces systèmes est un pas significatif vers une automatisation utile.

La vision plus large de MCP

Cela fait partie d’une tendance plus large : les serveurs MCP deviennent le moyen standard par lequel les agents IA interagissent avec le monde extérieur. On les voit pour GitHub, Azure DevOps, les bases de données, les APIs SaaS — et Foundry devient le hub où toutes ces connexions convergent.

Si vous construisez des agents dans l’écosystème .NET, MCP mérite votre attention. Le protocole est standardisé, l’outillage mûrit, et l’intégration Foundry le rend accessible sans avoir à câbler manuellement les connexions serveur.

Pour conclure

Le serveur MCP Azure DevOps dans Foundry est en preview, alors attendez-vous à ce qu’il évolue. Mais le workflow de base est solide : connecter, configurer l’accès aux outils, et laisser vos agents travailler avec vos données DevOps. Si vous êtes déjà dans l’écosystème Foundry, c’est à quelques clics. Essayez et voyez quels workflows vous pouvez construire.

Consultez l’annonce complète pour la configuration étape par étape et plus de détails.

Les réponses en arrière-plan dans Microsoft Agent Framework : fini l'angoisse des timeouts

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

Si vous avez construit quoi que ce soit avec des modèles de raisonnement comme o3 ou GPT-5.2, vous connaissez la douleur. Votre agent commence à réfléchir à une tâche complexe, le client attend, et quelque part entre “ça va” et “est-ce que ça a planté ?” votre connexion expire. Tout ce travail ? Perdu.

Microsoft Agent Framework vient de livrer les réponses en arrière-plan — et honnêtement, c’est une de ces fonctionnalités qui auraient dû exister depuis le premier jour.

Le problème avec les appels bloquants

Dans un schéma requête-réponse traditionnel, votre client bloque jusqu’à ce que l’agent termine. Ça marche bien pour les tâches rapides. Mais quand vous demandez à un modèle de raisonnement de faire une recherche approfondie, une analyse en plusieurs étapes, ou de générer un rapport de 20 pages ? Vous regardez des minutes de temps réel. Pendant cette fenêtre :

Les connexions HTTP peuvent expirer
Les coupures réseau tuent toute l’opération
Votre utilisateur fixe un spinner en se demandant s’il se passe quelque chose

Les réponses en arrière-plan inversent la donne.

Comment fonctionnent les tokens de continuation

Au lieu de bloquer, vous lancez la tâche de l’agent et récupérez un token de continuation. Pensez-y comme un ticket de retrait dans un atelier de réparation — vous ne restez pas debout au comptoir à attendre, vous revenez quand c’est prêt.

Le flux est direct :

Envoyez votre requête avec AllowBackgroundResponses = true
Si l’agent supporte le traitement en arrière-plan, vous recevez un token de continuation
Interrogez à votre rythme jusqu’à ce que le token retourne null — ça signifie que le résultat est prêt

Voici la version .NET :

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Interroger jusqu'à complétion
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Si l’agent finit immédiatement (tâches simples, modèles qui n’ont pas besoin de traitement en arrière-plan), aucun token de continuation n’est renvoyé. Votre code fonctionne simplement — aucun traitement spécial nécessaire.

Streaming avec reprise : la vraie magie

Le polling convient pour les scénarios fire-and-forget, mais que faire quand vous voulez un progrès en temps réel ? Les réponses en arrière-plan supportent aussi le streaming avec reprise intégrée.

Chaque mise à jour streamée porte son propre token de continuation. Si votre connexion tombe en plein stream, vous reprenez exactement là où vous en étiez :

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simuler une interruption réseau
}

// Reprendre exactement là où nous en étions
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

L’agent continue le traitement côté serveur indépendamment de ce qui se passe avec votre client. C’est de la tolérance aux pannes intégrée sans que vous écriviez de la logique de retry ou des circuit breakers.

Quand utiliser ça concrètement

Tous les appels d’agent n’ont pas besoin de réponses en arrière-plan. Pour les completions rapides, vous ajoutez de la complexité pour rien. Mais voici où elles brillent :

Tâches de raisonnement complexe — analyse en plusieurs étapes, recherche approfondie, tout ce qui fait vraiment réfléchir un modèle de raisonnement
Génération de contenu long — rapports détaillés, documents en plusieurs parties, analyses approfondies
Réseaux peu fiables — clients mobiles, déploiements edge, VPN d’entreprise instables
Patterns UX asynchrones — soumettez une tâche, allez faire autre chose, revenez pour les résultats

Pour nous développeurs .NET qui construisons des apps enterprise, ce dernier point est particulièrement intéressant. Pensez à une app Blazor où un utilisateur demande un rapport complexe — vous lancez la tâche de l’agent, affichez un indicateur de progression, et le laissez continuer à travailler. Pas d’acrobaties WebSocket, pas d’infrastructure de file d’attente personnalisée, juste un token et une boucle de polling.

Pour conclure

Les réponses en arrière-plan sont disponibles maintenant en .NET et Python via Microsoft Agent Framework. Si vous construisez des agents qui font plus que du simple Q&A, ça vaut le coup de l’ajouter à votre boîte à outils. Le pattern du token de continuation garde les choses simples tout en résolvant un vrai problème de production.

Consultez la documentation complète pour la référence API complète et plus d’exemples.

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”.

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.

Contribuer à The .NET Blog

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog est une publication communautaire où les développeurs partagent des analyses, des tutoriels et des histoires sur .NET, Azure, l’IA et le développement cloud-native. Nous accueillons les contributions de développeurs de tous niveaux — que vous écriviez votre premier article technique ou que vous soyez un conférencier expérimenté.

Comment rejoindre

Tout se passe sur GitHub avec un workflow de pull requests. Voici comment commencer :

1. Forker le dépôt

Rendez-vous sur github.com/thedotnetblog/blog et forkez le dépôt sur votre compte GitHub.

2. Créer votre profil d’auteur

Si c’est votre première contribution, ajoutez-vous comme auteur en créant un dossier dans content/authors/your-username/ avec un fichier index.md contenant votre nom, rôle et biographie. Ajoutez votre image d’avatar (carrée, au moins 200x200px) dans static/img/authors/.

3. Rédiger votre article

Créez un nouveau dossier dans content/posts/your-username/your-post-slug/ et ajoutez un fichier index.md avec le titre, la date, l’auteur, la description et les tags.

4. Ouvrir une Pull Request

Poussez vos modifications sur votre fork et ouvrez une pull request vers la branche main. Notre équipe la passera en revue et fournira des commentaires dans les quelques jours.

Ce que nous recherchons

Tutoriels — guides pas à pas sur .NET, Azure, IA, Blazor, Aspire et plus
Analyses approfondies — explorations détaillées d’une technologie, d’un pattern ou d’une architecture
Histoires de la communauté — votre expérience avec .NET en production
Résumés d’événements — comptes-rendus de conférences, meetups ou webinaires

Directives

Le contenu doit être technique et pertinent pour l’écosystème .NET
Les exemples de code doivent être exacts et testés dans un vrai projet
Inclure une description significative et au moins un tag pertinent
Les articles sont automatiquement traduits dans toutes les langues supportées

Contact

Ouvrez une issue sur GitHub ou contactez-nous sur X / Twitter. Nous serions ravis de vous accueillir dans la communauté !

Emiliano Montesdeoca

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog

NDC Oslo 2026

En chiffres

Speakers confirmés

Billets

Autres événements NDC en 2026

Liens

.NET Day Switzerland 2026

Ce qui vous attend

Billets

Organisateurs

Liens

SDD Conference 2026

Sujets

Speakers

Billets et informations

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

Support des Requêtes WIQL

Personal Access Tokens

Annotations MCP

Consolidation des Outils Wiki

Expérimental : MCP Apps

SQL Server 2025 comme Base de Données Prête pour les Agents : Sécurité, Backup et MCP dans un Seul Moteur

Un Modèle de Sécurité pour Tous les Modèles de Données

Backup Unifié = Récupération Atomique

Intégration MCP : Agents Sans Middleware

Conclusion

.NET 10 Est Livré avec Ubuntu 26.04 LTS — Ce qui Est Nouveau

Installer .NET 10 en deux commandes

Conteneurs : mettre à jour -noble vers -resolute

Native AOT : démarrage en 3ms, binaire de 1,4MB

Besoin de .NET 8 ou 9 ?

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

Qu’est-ce qu’un MCP Bundle ?

Comment l’installer

Ce que vous pouvez faire avec

Pour commencer

Azure SDK Avril 2026 : AI Foundry 2.0 et Ce Que les Développeurs .NET Doivent Savoir

Azure.AI.Projects 2.0.0 — Changements Cassants Qui Font Sens

Cosmos DB Java : Correctif de Sécurité Critique (RCE)

Nouvelles Bibliothèques de Provisioning pour .NET

Conclusion

CodeAct dans Agent Framework : Comment Réduire la Latence de votre Agent de Moitié

Qu’est-ce que CodeAct ?

Sécurité : Micro-VMs Hyperlight

Configuration minimale

Quand utiliser CodeAct (et quand ne pas l’utiliser)

Essayez maintenant

GPT-5.5 Est Là et Arrive dans Azure Foundry — Ce que les Développeurs .NET Doivent Savoir

La progression de GPT-5

Ce qui a vraiment changé

Tarification

Pourquoi Foundry est important

Où votre Agent se Souvient-il des Choses ? Guide Pratique sur le Stockage de l'Historique de Chat

Deux modèles fondamentaux

Comment Agent Framework abstrait cela

Référence rapide des fournisseurs

Comment choisir

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

Copilot CLI : les sessions ont de vrais noms

Changer de session plus rapidement

Badges de modèle dans le chat

Sélection automatique de modèle dans Copilot CLI

Opt-in TypeScript 7.0 Nightly

Aspire 13.2 : Support Bun, Meilleurs Conteneurs et Moins de Friction de Debug

Bun est Maintenant Citoyen de Première Classe

Yarn Plus Fiable

Améliorations des Conteneurs

Améliorations du Débogage

Conclusion

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

Le Mensonge de la Fenêtre de Contexte

La Taxe de Compactage

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

En Conclusion

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

Qu’est-ce qu’une Toolbox ?

Les quatre piliers (deux disponibles aujourd’hui)

Exemple pratique

Pas d’enfermement dans Foundry Agents

Conteneurs : mettre à jour `-noble` vers `-resolute`