.NET 11 RC1 : unions en C# 15, Blazor agentique et un bond visible dans la vitesse des outils

Annoncée le mardi qui suivait un week-end de trois jours, la Release Candidate 1 de .NET 11 est arrivée avec son billet de publication et ses notes détaillées le même jour. L'émission en direct s'est ouverte dans une ambiance festive, a diffusé une animation amusante partagée dans le chat et a promis une introduction encore plus spectaculaire pour la RC2. Pour moi, le stade RC est celui où les expérimentations s'achèvent et où les répétitions de production commencent, et cette émission portait exactement ce sérieux.

Côté C# 15, les types union ont été la vedette. La démo est partie d'un code familier mais défectueux : plusieurs types proches d'animaux, sans lien entre eux, transportés comme de simples objets parce qu'ils ne partagent aucune bibliothèque. Le compilateur ne peut rien vérifier là ; un type non animal peut se glisser silencieusement dans la liste et n'exploser qu'à l'exécution. La nouvelle syntaxe d'union transforme ce désordre en concept de langage de premier ordre.

Le nouveau compilateur comprend les conversions implicites vers des valeurs d'union et vérifie les expressions switch qui couvrent tous les cas. Une branche manquante apparaît désormais comme une erreur de compilation au lieu d'une surprise à l'exécution. Pour les bibliothèques existantes qui se comportent déjà comme des unions, une porte de sortie par attribut existe : les types exposant les membres recherchés par le compilateur bénéficient du traitement d'union sans adopter la nouvelle syntaxe. J'ai aussi noté que le billet sur les hiérarchies fermées est paru sur le blog le même jour.

Le segment ASP.NET Core s'est articulé autour de six thèmes majeurs : des fondamentaux renforcés, la sécurité, la performance et l'observabilité. L'équipe a déclaré s'être concentrée sur des points de douleur de longue date issus des retours utilisateurs, visant les services modernes construits avec les API minimales et Blazor. Faciliter les configurations distribuées avec l'équipe Aspire faisait partie du même récit.

La nouvelle la plus concrète en matière de validation fut les règles asynchrones. Les annotations de données classiques sont entièrement synchrones ; il n'existait aucune réponse au niveau du langage pour des vérifications devant interroger une base de données ou appeler un service. Désormais, des modèles comme les objets de requête d'inscription et de réservation peuvent déclarer des règles telles qu'e-mail unique et nom d'utilisateur unique. L'exemple d'API minimale montrait ces règles posées directement sur les types de requête.

L'expérience utilisateur a aussi été prise en compte : le formulaire lit, via le contexte d'édition, si les vérifications sont en attente, en échec ou valides. La démo utilisait de petits composants personnalisés pour afficher ces états ; ils ne font pas partie du framework, mais ils étaient simples à écrire. À mesure que l'utilisateur tape, les vérifications de disponibilité s'exécutent et l'interface reflète instantanément l'état. Ce détail fait, à mon avis, passer la validation asynchrone de la décoration de démo à quelque chose de livrable.

La même section cachait une surprise de localisation : en basculant le formulaire en espagnol, tout a été localisé proprement, y compris les règles asynchrones personnalisées. Les messages intégrés pour les champs requis et le format d'e-mail ont aussi été localisés, sans ajouter de propriétés supplémentaires aux attributs. L'équipe a souligné que cette simplification est nouvelle dans la RC1. Tous ceux qui livrent des formulaires multilingues vont respirer plus facilement.

Presque toutes les applications modernes sont distribuées : un frontend, plusieurs services backend, une base de données, un cache et des services d'IA. Les exécuter ensemble en local, les laisser se découvrir, câbler l'observabilité de bout en bout et livrer l'ensemble est un travail à part entière. Le segment Aspire de l'émission ciblait exactement cette douleur. Conserver la même topologie du développement à la production m'a semblé être la promesse qui fera gagner le plus d'heures.

Pour Blazor WebAssembly, un package de valeurs par défaut spécifiques au client a été introduit ; les besoins de configuration de l'exécution dans le navigateur vivent dans leur propre projet. Un nouveau modèle de projet échafaude ce squelette en une seule recherche. Frontend, backend et orchestration se retrouvent alors côte à côte dans la même solution. Le modèle met fin à l'ère de la mémorisation des docs d'installation.

La modélisation se fait dans le projet hôte de l'application avec un package d'intégration spécifique à Blazor : le service backend est ajouté comme d'habitude, tandis que le projet WebAssembly rejoint l'orchestration comme participant de premier ordre et déclare sa dépendance à l'API. Grâce à ce modèle, l'orchestrateur sait quelle pièce est l'application navigateur et la traite en conséquence. Quelques lignes de déclaration se transforment en un sérieux confort d'exécution.

La nouvelle passerelle Blazor a été présentée comme un composant d'hébergement prêt pour la production qui sert de proxy aux requêtes. Elle remplace l'ancien serveur de développement, si bien que développement et production partagent la même histoire d'hébergement. Les règles de découverte de services circulent du client vers le backend sans lutte inter-origines. Faire circuler la configuration du backend vers le frontend est aussi le rôle de la passerelle.

La démo en direct a tracé le chemin complet à travers une page météo : l'application navigateur a appelé la passerelle, la passerelle a joint le service backend, et la découverte s'est résolue toute seule. Côté tableau de bord, les traces et métriques de l'application, de la passerelle et du service ont fusionné en une vue unique. Le parcours de la requête, du clic dans le navigateur à la réponse du backend, pouvait être suivi pas à pas dans la vue des traces. Dans les systèmes distribués, cette visibilité est une nécessité, pas un luxe.

La section web agentique a introduit les composants Blazor AI comme bibliothèque expérimentale. L'idée est simple : au lieu de se perdre dans les menus et de lire des manuels, les utilisateurs accomplissent leurs tâches en parlant à un assistant au sein de l'application. Les composants rendent ces expériences d'assistant peu coûteuses à construire. J'y ai lu un frontend qui apprend à se comporter comme une ligne de commande.

Le protocole sous-jacent, AGUI, a été décrit comme le canal entre les agents et les interfaces humaines ; contrairement aux protocoles agent-à-agent et d'outils, son focus est l'interaction avec les personnes. L'application de recettes de la démo montrait l'assistant modifiant l'état d'une recette en temps réel. Le même schéma s'est répété sur trois démos distinctes, ce qui me dit que l'équipe a transformé ce flux en habitude.

Les appels d'outils côté backend ont été visualisés avec un exemple météo : quand l'utilisateur a demandé la météo de Seattle, l'assistant a invoqué l'outil pertinent, et le bloc correspondant dans l'historique de conversation a été intercepté et rendu sous forme de carte météo personnalisée. La carte affichant vingt degrés et du soleil a fait rire la salle. L'implémentation reposait sur un assistant équipé du package d'extensions plus un moteur de rendu associant les blocs côté client. Le schéma est limpide : chaque appel d'outil peut devenir une pièce d'interface sur mesure.

Les appels d'outils côté frontend passent par le même protocole : une capacité côté client, comme changer la couleur d'accent de l'interface, est annoncée à l'assistant côté serveur. Dans la démo, l'accent est passé au vert et le frontend s'est mis à jour instantanément. La configuration se limite à enregistrer une action d'interface et à surveiller les blocs entrants. L'intelligence côté serveur atteint ainsi une main côté client.

La plus grande mais la plus discrète nouvelle MAUI fut le changement de runtime : abandonner l'ancien runtime monolithique pour le même runtime central que le reste de l'écosystème. Ce n'est pas un bouton que les utilisateurs verront ; au contraire, passer inaperçu compte comme un succès. En contrepartie, les outils standards de profilage et de traçage fonctionnent dès l'installation. Tout investissement futur dans les outils est prévu sur cette base.

Côté visible, l'équipe s'est attaquée à des années de petites irritations accumulées, avec un assistant de codage faisant le gros du travail. L'application de programme de la conférence dans la démo a été générée de bout en bout par l'assistant ; même le tableau de mission sur le thème de la fusée, le mode sombre et la mignonne icône de robot étaient ses idées. En pleine démo, le présentateur a ouvert l'éditeur pour montrer un détail oublié et est passé à la suite sans taper une seule ligne. Le message à tous ceux qui trouvaient MAUI intimidant était clair : c'est le moment d'essayer.

Côté cartes, le clustering et les icônes personnalisées sont désormais livrés en standard ; des tâches qui exigeaient autrefois des gestionnaires personnalisés se résolvent avec une seule fonctionnalité. Les écrans de démarrage en mode clair et sombre ont été tout aussi simplifiés. Les expressions C d'exemples générées à la source, activées par défaut dans .NET 11, ont aussi été annoncées, présentées comme des améliorations bien-aimées du langage de balisage après vingt années de silence. Toute personne nerveuse à l'idée du langage de balisage a été invitée à laisser l'assistant l'écrire.

DevFlow, parmi les outils assistés par agent, est né en réponse à la douleur de l'automatisation qui capture le curseur : au lieu de faire des captures d'écran, de deviner les coordonnées des clics et de verrouiller la souris de l'utilisateur entre-temps, il promet une vision et une interaction dans l'application. L'implémentation sera réservée à l'émission RC2, les animateurs ont souligné qu'elle était révélée ici en premier. Être mentionné aux côtés des outils IA des labs MAUI montre clairement la direction.

Le segment SDK et MSBuild a expliqué pourquoi la performance compte désormais : plus de pipelines d'intégration continue que jamais, des boucles d'assistants s'exécutant en parallèle, et de petits outils en ligne de commande invoqués encore et encore. Chaque invocation paie un tribut : démarrer l'application, charger le runtime central et interpréter la commande. Des techniques de compilation anticipée sont utilisées pour réduire ce coût de démarrage. L'exposé a cadré l'évolution de la relation entre développeur et outils, avec plusieurs arbres de travail et assistants tournant côte à côte sur une même machine.

Un processus serveur MSBuild persistant arrive : au lieu du modèle par lots à requête unique, une structure qui conserve l'état entre les builds, comparée à la façon dont le compilateur pré-moderne reconstruisait son univers à chaque commande. Sur une solution échantillon de trois projets, le temps de build sans modification a chuté d'environ un tiers. Pour les builds multi-threadés, l'objectif est le partage en processus au lieu d'exécuter chaque projet dans son propre processus. Des améliorations de contributeurs ont aussi rendu les images de conteneur déterministes et les poussées vers le registre plus rapides, avec une conteneurisation en ligne de commande visiblement plus rapide.

Côté bibliothèques, le présentateur a couvert un spectre allant du microcode JIT aux analyseurs numériques avec deux ajouts : une nouvelle API d'analyse qui balaie les séparateurs en une seule passe au lieu de les parcourir deux fois, et des centaines de fonctions incluant des sommes accélérées dans les travaux décimaux et à virgule flottante. Les formats flottants hexadécimaux, les littéraux binaires et le support de la mathématique générique forment un champ trop vaste pour une démo de dix minutes. La conclusion a ramené le C# dev kit à un seul processus : environ une baisse de mémoire de quatre-vingt-cinq pour cent à 243 mégaoctets, quatre ou cinq instances dans le même espace, un démarrage de solution accéléré grâce à un fichier de cache, et des démarrages rapides depuis un binaire compilé nativement. Le billet annuel sur la performance est proche, ont dit les animateurs, et la série continue avec l'émission RC2.