📦 Actualités des versions
La version stable la plus récente est .NET 10.0.12 (publiée le 8 septembre 2026). Pour les applications d’entreprise en cours de maintenance ou en préparation de migration, vous pouvez consulter notre analyse des fonctionnalités clés de C# 14 afin de passer en revue les changements majeurs de la génération précédente.
Parallèlement, .NET 11 Release Candidate 1 (RC 1) est sortie le 8 septembre 2026 (avec une dernière révision sur le blog officiel le 24 septembre). Cette version bénéficie d’une licence de support commercial « Go-Live », ce qui autorise son déploiement en production. Les évolutions majeures de cette RC 1 incluent :
| Changement | Impact concret |
|---|---|
| Optimisations de bas niveau du JIT et du GC | Introduction de stratégies d’inlining plus agressives et d’une logique d’allocation mémoire affinée. Le temps de cold start et la fragmentation mémoire diminuent sensiblement sous forte concurrence, un atout clé pour les conteneurs aux ressources limitées. |
| Périmètre fonctionnel de C# 15 finalisé | L’extension du pattern matching et l’assouplissement de l’inférence de types sont désormais figés, éliminant une quantité notable de boilerplate. La maintenance des modèles de domaine complexes et des moteurs de règles s’en trouve grandement allégée. |
| Améliorations de l’outillage .NET SDK | Accélération notable de la résolution des dépendances dans MSBuild et NuGet. Pour les solutions d’envergure dépassant 50 dépendances de projets, les pipelines CI/CD constatent un gain de temps de compilation de 15 à 20 %. |
📝 Décryptage
1. Publication officielle du SDK .NET AG-UI : standardisation des interactions avec les agents
Ce qui s’est passé : En partenariat avec CopilotKit, l’équipe .NET a publié les bibliothèques AGUI.Server et AGUI.Client sur le flux officiel NuGet sous licence MIT. Ce SDK remplace les couches internes de l’ancien Microsoft Agent Framework (MAF) par le protocole standardisé Agent-User Interaction (AG-UI).
Pourquoi c’est important : Jusqu’ici, développer un agent IA imposait de gérer manuellement des formats de streaming fragmentés selon les modèles et les frameworks front-end. Le protocole AG-UI fournit un flux d’événements indépendant du langage, encapsulant le comportement de l’agent au fil d’une connexion persistante via des événements stricts tels que RUN_STARTED, TEXT_MESSAGE_CONTENT ou STATE_DELTA. Les méthodes clés ToChatRequestContext et AsAGUIEventStreamAsync intègrent une sérialisation bidirectionnelle complexe, y compris la gestion des interruptions.
Qui est concerné : Les développeurs de services IA multiplateformes. Il suffit désormais de maintenir un unique backend C# ASP.NET Core architecturé autour de IChatClient, directement consommable par des clients .NET natifs ou par l’écosystème front-end TypeScript (React/Vue).
Lien source : AG-UI Protocol now has a first-class .NET SDK
2. Blazor AI Components : repenser l’UI agentique (Agentic UI)
Ce qui s’est passé : S’appuyant sur le nouveau SDK .NET 11 RC 1, Microsoft a introduit le package d’interface expérimental Microsoft.AspNetCore.Components.AI. Son composant central, <ChatPage Agent="_agent" Placeholder="Ask me anything…" />, prend en charge le rendu et le contrôle en direct du flux d’état d’un UIAgent.
Pourquoi c’est important : Une simple zone de texte de chat ne suffit plus aux besoins métier élaborés. Les utilisateurs doivent visualiser les étapes intermédiaires d’exécution d’un agent et interagir avec l’état partagé (Shared State). Blazor AI introduit un mécanisme de ContentBlock qui projette dialogues, appels d’outils (Tool Calls) et validations de permissions sous forme de composants Razor concrets. L’interface sous-jacente peut dialoguer directement avec Microsoft.Extensions.AI ou encapsuler AGUIChatClient pour cibler des endpoints distants.
Qui est concerné : Les développeurs full-stack Blazor. Fini l’écriture manuelle et sujette aux erreurs de machines à états WebSocket/SSE : le modèle de composants fortement typé de C# permet d’assembler des panneaux Copilot d’entreprise à moindre coût.
Lien source : Build Agentic UI with the new Blazor AI components
3. NetWasm : un runtime .NET autonome de 82,5 Ko
Ce qui s’est passé : Le projet indépendant NetWasm s’est illustré sur Hacker News en proposant un compilateur et un runtime .NET entièrement exécutés dans le navigateur via WebAssembly. Le module minimal Hello World C# compilé ne pèse que 82,5 Ko, ce qui a vivement retenu l’attention.
Pourquoi c’est important : Bien que la filière officielle Native AOT offre d’excellentes performances brutes, elle souffre d’un encombrement incompressible de ses bibliothèques de base et dépend d’une chaîne de compilation serveur conséquente lorsqu’elle vise le pur front-end. NetWasm contourne ces contraintes en exécutant une logique de compilation csc ultra-légère directement côté client pour émettre des binaires Wasm compacts.
Qui est concerné : Les développeurs front-end très attentifs au poids de leurs bundles et les passionnés de WebAssembly. Le projet n’en est qu’à ses débuts (arbres d’expression complets et multithreading via Web Workers manquent encore à l’appel), mais il valide la viabilité d’un micro-runtime C# autonome dans le navigateur.
Liens sources : NetWasm Playground | Discussion sur HN
4. Dumps mémoire natifs en C# et interopérabilité moderne
Ce qui s’est passé : L’équipe .NET détaille dans un article de fond comment intégrer des mécanismes d’auto-diagnostic directement au sein du code C#, afin de déclencher automatiquement un dump mémoire lors d’incidents complexes à tracer par de simples logs, comme la saturation du pool de threads (Thread Pool Saturation).
Pourquoi c’est important : La capture de dumps mémoire repose souvent sur des outils externes (tels que ProcDump de Sysinternals ou des commandes système privilégiées sous Linux). L’équipe présente un modèle de surveillance embarqué : un thread dédié ThreadPoolWatcher vérifie régulièrement la latence d’exécution des Task en arrière-plan. Dès qu’un seuil critique est dépassé, le code sollicite directement dbghelp.dll (MiniDumpWriteDump) sous Windows ou l’utilitaire interne createdump sous Linux pour générer un fichier de 125 Mo à 800 Mo. Les échanges ont également mis en lumière l’arbitrage de performances entre l’ancien [DllImport] et les générateurs de code modernes [LibraryImport].
Qui est concerné : Les architectes microservices back-end et les ingénieurs SRE. Cette approche d’auto-diagnostic automatise la collecte d’artefacts lors des pannes en production, réduisant drastiquement le temps moyen de résolution (MTTR) des deadlocks et des épuisements de ressources bas niveau.
Lien source : Creating a memory dump in C#
🔥 Tendances de la communauté
1. Débat architectural : runtime léger indépendant contre Native AOT officiel
Lors de la présentation Show HN de NetWasm (5 points / 4 comments), les développeurs ont confronté leurs visions sur l’avenir de C# au sein de l’écosystème WebAssembly. Principaux points de friction :
- Les partisans de la parité : Ils estiment que les runtimes tiers doivent s’aligner sur les fonctionnalités les plus récentes du langage C#. L’enjeu est de permettre une migration transparente du code métier existant (back-end et desktop) vers le navigateur sans dégrader l’expérience de développement unifiée.
- Les partisans du minimalisme : Selon eux, viser l’exhaustivité dans un bac à sable de navigateur n’a pas de sens. La priorité stratégique devrait être de proposer — officiellement ou via la communauté — un sous-ensemble épuré de C# taillé pour le modèle mémoire de Wasm, quitte à délaisser une partie de l’héritage objet historique pour privilégier un chargement et une exécution ultra-rapides.
Lien source : Show HN: NetWasm
2. Yengi : la boîte à outils IA auto-réparatrice pour créateurs de jeux indépendants
Un développeur indépendant issu du milieu enseignant a partagé en open source Yengi (2 points / HN, relayé également sur Reddit et GitHub), un environnement de développement 3D assisté par IA basé sur .NET 8. Mécanismes remarqués :
- Le projet se distingue par un canal TCP Socket temps réel en C# qui pilote directement l’éditeur Unity, couplé à une boucle d’agent inédite baptisée « Self-Healing Repair Agent Loop ».
- Contrairement aux outils de génération de code statiques, lorsqu’un script de scène C# généré par l’IA rencontre une erreur de syntaxe à la compilation ou lève une exception à l’exécution, l’environnement hôte intercepte la stacktrace pour la réinjecter immédiatement au LLM. Celui-ci applique un correctif à chaud suivi d’un hot reload. Cette synergie entre réflexion fortement typée et compilation dynamique avec Roslyn ouvre un workflow agentique accessible et économique pour le prototypage indépendant.
Liens sources : GitHub - Yengi | Discussion sur HN
À suivre la semaine prochaine
La version finale de .NET 11 est confirmée pour novembre lors de la conférence .NET Conf 2026. D’ici là, l’ultime jalon de test, la RC 2, devrait paraître d’ici deux semaines. À ce stade du cycle, la RC 2 n’accueille plus aucune modification d’API publique et se concentre exclusivement sur les correctifs critiques de dernière minute. Il est vivement conseillé aux équipes techniques de tirer parti de la RC 1 dès à présent pour exécuter leurs tests de non-régression sur leurs bibliothèques stratégiques (notamment Entity Framework Core ou les packages gRPC tiers faisant un usage intensif de la réflexion), préparant ainsi une bascule sereine pour novembre.
