.NET 9 : les 5 nouveautés qui changent vraiment la donne

J'utilise .NET 9 en production depuis novembre 2024 sur plusieurs projets. On est en avril 2026, j'ai maintenant le recul qui manquait aux articles de sortie. Voici ce qui m'a vraiment changé la vie au quotidien, ce qui était surévalué dans le marketing Microsoft, et ce qui est réellement utile pour quelqu'un qui développe des apps métier.

Blazor United : la vraie révolution (pour moi)

Jusqu'à .NET 8, Blazor était une techno avec deux personnalités schizophréniques : Server (rapide à charger mais latence réseau) et WebAssembly (autonome mais lourd au démarrage). Dans les deux cas, on galérait pour le SEO d'un site public. Résultat : Blazor restait une techno de back-office.

Avec .NET 9, on peut mixer. Rendu statique par défaut sur une page (Google peut lire), hydration à la demande sur les zones interactives, streaming HTML. C'est ce que Next.js fait depuis deux ans côté React, Microsoft a enfin rattrapé. Concrètement : je peux désormais construire un site public E-commerce en Blazor sans rougir du SEO. C'est une vraie rupture, pas un marketing Microsoft.

Native AOT : fantastique pour certains cas, piège pour d'autres

Native AOT compile votre app .NET en binaire natif autonome. Mon API .NET 9 en AOT pèse 25 Mo dans Docker (au lieu de 200 Mo), démarre en 50 ms (au lieu de 2 s), et consomme 40 Mo de RAM au repos. Énorme pour du serverless ou pour densifier du Kubernetes.

Mais. Mais. Beaucoup de librairies NuGet ne supportent pas encore AOT. Reflection, dynamic code generation, certains ORM, beaucoup de middlewares. J'ai passé deux jours à debugger une app qui crashait en prod parce qu'AutoMapper faisait du runtime IL emission. Mon conseil : AOT pour les APIs nouvelles sans dettes, pas pour migrer un monolithe existant.

OpenAPI natif : enfin. Vraiment.

Pendant 10 ans, tout le monde installait Swashbuckle.AspNetCore pour exposer un Swagger. La lib était bien mais un peu lourde, des surprises sur le JSON généré, la maintenance s'est essoufflée. .NET 9 intègre OpenAPI nativement. Un AddOpenApi() dans Program.cs, et c'est réglé. Plus besoin de dépendance tierce.

Petit bémol : l'UI Swagger n'est pas fournie (il faut ajouter Scalar ou ReDoc à la main). Pour moi ce n'est pas un problème, Scalar est plus joli de toute façon.

EF Core 9 : les gains qu'on sent vraiment

20 à 50 % de gains de perfs, c'est ce que Microsoft annonce. Sur mes projets, je constate plutôt 15 à 30 % selon les requêtes. Honnête donc. Les nouveautés Complex Types (pour faire du DDD propre avec des Value Objects) sont un game-changer pour ceux qui font de l'architecture propre. Fini les shadow properties et les ugly mappings.

Ce dont on parle moins mais qui compte

Le Hybrid Cache dans .NET 9 (Microsoft.Extensions.Caching.Hybrid) : cache L1 en mémoire + L2 Redis en transparent, sans écrire la plomberie. Ça économise 50 lignes par projet. Le ProblemDetails amélioré pour les erreurs HTTP (RFC 7807) : maintenant standard, plus besoin de le bricoler. Et dans System.Text.Json, le support des interfaces en sérialisation : ça débloque des patterns que j'attendais depuis des années.

Faut-il migrer ? Réponse honnête

.NET 9 est STS : support 18 mois seulement. .NET 10 LTS sort fin 2026 avec 3 ans de support. Si vous êtes en .NET 8 LTS, ne migrez PAS vers .NET 9 juste pour être à jour. Attendez .NET 10. Si vous démarrez un nouveau projet début 2026, prenez .NET 9 direct (vous passerez sur .NET 10 en novembre, c'est transparent). Si vous êtes encore en .NET Framework 4.x, appelez-moi, on a du boulot.