C# moderne et le runtime .NET

C# moderne et le runtime .NET

1. Choisir sa version : ce qui n'est pas négociable

   Une version sortie de support ne reçoit plus de correctifs de sécurité. C'est le seul critère qui doit décider, parce qu'il conditionne l'extérieur du projet : la conformité, la sécurité, la responsabilité contractuelle.

   Le rythme des versions

   Une version majeure par an, en novembre. L'alternance est fixe : les années impaires donnent une version LTS (support de trois ans), les années paires une version STS (deux ans). La qualité est identique dans les deux cas — seule la durée de support diffère. Un cours qui laisse croire qu'une version STS est moins bonne se trompe.

   L'état réel, relevé en septembre 2026

   Version	Type	Phase	Fin de support
   .NET 10	LTS	active	14 novembre 2028
   .NET 9	STS	maintenance	10 novembre 2026
   .NET 8	LTS	maintenance	10 novembre 2026

   La ligne à retenir pour un projet qui démarre : viser la LTS en vigueur, ici .NET 10. Deux conséquences pratiques :

   • .NET 8, longtemps référence comme « la LTS », cesse d'être soutenue dans moins de deux mois. Un projet neuf ne doit pas y démarrer ; un projet existant doit planifier la migration ;
   • la phase « maintenance » ne corrige plus que les failles de sécurité, plus aucune fonctionnalité. Une version qui y entre reste utilisée en production par des applications qui ne peuvent pas migrer, ce qui est la situation par défaut d'une grande partie du parc .NET en entreprise.

   Le tableau se vérifie en deux clics sur la page de support officielle. Le recopier ici ne le périme pas : c'est la page qui fait foi, et c'est elle qu'un projet doit consulter au moment de son arbitrage.

2. Types, nullabilité et unmistakable

   C# est à typage statique : le type est connu à la compilation, et le vérificateur de nullité est activé par défaut. Ce second point est un changement majeur par rapport à l'usage courant du langage.

   Les types de valeur et les types de référence

   Un type de valeur contient sa donnée ; un type de référence contient une adresse. La conséquence : copier un type de valeur duplique la donnée, copier un type de référence copie l'adresse — les deux pointent alors vers le même objet. Comprendre cette différence évite une famille entière de bugs où l'on croit modifier une copie.

   La nullabilité, compilée

   Une référence peut ne pointer vers rien. Le langage le signale dans le type : string garantit non nul, string? indique qu'il peut l'être. L'avertissement n'est pas un avertissement, c'est une erreur de compilation.

   C'est le meilleur rapport qualité/prix de l'écosystème C# moderne : impossible de déréférencer une référence nulle sans que le compilateur l'ait signalé. Ce qui n'est pas traité reste à traiter — avec un motif explicite, jamais un simple null-forgiving operator posé pour faire disparaître l'erreur.

   Les types immuables : records

   Un record définit une valeur dont l'identité est son contenu, pas sa référence. Il est par défaut immuable et fournit nativement l'égalité par valeur, que les classes ne donnent pas. Pour un objet de transfert — un résultat de calcul, une ligne de commande, une réponse d'API, c'est le bon choix par défaut, et l'expression with permet de dériver une version modifiée sans muter l'original.

   Attention à ne pas confondre : record class reste une référence, record struct est un type de valeur. Le choix change la sémantique de passage.

3. Asynchrone : await, annulation, pièges

   Toute opération réseau ou d'entrée-sortie est asynchrone. Le mot-clé async/await libère le thread pendant l'attente, ce qui permet à un serveur de servir des milliers de requêtes avec peu de threads.

   Pourquoi await est préférable à .Result

   Bloquer sur une tâche asynchrone avec .Result ou .Wait() provoque un interblocage dans un contexte de synchronisation : le thread qui doit exécuter la suite attend un résultat qui ne peut pas être produit, parce que le thread nécessaire est bloqué. Le programme se fige, sans message d'erreur. C'est le piège le plus coûteux du langage, parce qu'il ne se manifeste qu'en application web, jamais dans un exécutable console.

   L'annulation n'est pas optionnelle

   Une opération asynchrone doit accepter un jeton d'annulation et le transmettre à toutes les opérations en aval. C'est ce qui permet, lorsqu'un utilisateur ferme un onglet ou change de page, d'interrompre le travail au lieu de le laisser s'exécuter jusqu'au bout pour un résultat que plus personne ne lira. Le serveur ne s'en rend pas compte tout seul.

   La règle : une signature asynchrone qui ne prend pas de jeton d'annulation est incomplète.

   Les deux pièges de performance

   1. l'accès concurrent à une collection : une liste ordinaire lue pendant qu'elle est écrite lève une exception ou produit un résultat faux, de façon imprévisible. La version asynchrone, prévue pour, ou un verrou explicite ;
   2. l'async sans await : une méthode marquée async sans await génère un avertissement et s'exécute de façon synchrone, ce qui crée une attente bloquante déguisée.

   La règle de conception qui évite les deux : propager le jeton d'annulation jusqu'aux feuilles de l'arbre d'appels, plutôt que de l'absorber au niveau du service. Une exception capturée et ignorée en cours de route est le moyen le plus sûr de perdre une annulation sans le voir.