Dotnet | The .NET Blog

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

Dotnet | The .NET Blog

SDD Conference 2026

Sujets

Speakers

Billets et informations

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

Les hooks, en bref

Comment fonctionne la détection

Détails par langage

Python

JavaScript et TypeScript

.NET

Configuration par exécuteur

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

Conclusion

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

winapp run : F5 depuis n’importe où

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

winapp ui : UI Automation depuis la ligne de commande

Autres nouveautés

Installation

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

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

Gérer ce qui tourne

Combinez-le avec le mode isolé

Pourquoi c’est énorme pour les agents de code

Pour conclure

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

Une propriété pour les gouverner tous

Groupes de clustering indépendants

Gestion des taps sur les clusters

Détails de plateforme à connaître

Pourquoi c’est important

Pour commencer

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

Ce qui a été corrigé

Versions mises à jour

Que faire

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

Qu’est-ce qu’Azure MCP Server ?

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

Renforcement de la sécurité

Où pouvez-vous l’utiliser ?

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

Démarrage

Conclusion

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

Le problème est réel

Aspire comme infrastructure pour agents

L’analogie des bumpers de bowling

Pour démarrer

Pour conclure

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

Pourquoi cette combinaison a du sens

Options d’authentification

Mise en place

Mon avis

Pour conclure

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

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

Deux façons de commencer

Le détail des issues est actionnable

Les chemins de mise à jour couverts

Mon avis

Pour conclure

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

La solution : --isolated

Scénarios réels où ça brille

Comment ça fonctionne sous le capot

Quand l’utiliser

Pour conclure

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

Qu’est-ce que les MCP Apps ?

L’API fluide en trois étapes

La surface de l’API est bien conçue

Pour commencer

Pour conclure

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

Le problème que les unions résolvent

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

La solution : `--isolated`