C# accueille les types union en novembre - un rattrapage qui rapproche le langage de F# et Rust

Microsoft confirme via The Register l'arrivée des types union dans C# en novembre 2026. Une fonctionnalité que TypeScript, Rust, Swift et F# ont depuis longtemps, et qui change la manière de modéliser les états métier en C#.

Le cas concret

Combien de fois avons-nous écrit ce genre de code en C# pour représenter un état qui peut prendre trois formes distinctes ?

public class RésultatPaiement
{
 public bool EstSuccès { get; set; }
 public string? IdTransaction { get; set; }
 public bool EstEnAttente { get; set; }
 public string? RaisonAttente { get; set; }
 public bool EstErreur { get; set; }
 public string? CodeErreur { get; set; }
 public string? MessageErreur { get; set; }
}

Un objet où trois booléens s'excluent mutuellement, cinq champs nullable qui n'ont de sens qu'en combinaison avec un booléen précis, et zéro garantie du compilateur qu'on n'oublie pas un cas dans le if/else. Bienvenue dans la modélisation par convention, qui repose sur la discipline du développeur - c'est-à-dire pas grand-chose.

Ce qui arrive

The Register annonce le 2 septembre 2026 que Microsoft a confirmé l'arrivée des types union - également appelés « discriminated unions » ou « sum types » - dans C# en novembre 2026.

L'idée est simple : plutôt qu'un objet à cinq champs qui « peut être un succès, une attente ou une erreur », on déclare explicitement au compilateur que le type est l'un de trois cas mutuellement exclusifs, chacun avec ses propres champs pertinents.

En pseudo-C# (la syntaxe finale sera annoncée officiellement) :

public union RésultatPaiement
{
 Succès(string IdTransaction);
 Attente(string Raison);
 Erreur(string Code, string Message);
}

// Utilisation
switch (résultat)
{
 case RésultatPaiement.Succès s: 
 Console.WriteLine($"Transaction {s.IdTransaction}"); 
 break;
 case RésultatPaiement.Attente a: 
 Console.WriteLine($"En attente : {a.Raison}"); 
 break;
 case RésultatPaiement.Erreur e: 
 Console.WriteLine($"Erreur {e.Code} : {e.Message}"); 
 break;
 // Le compilateur signalera si un cas manque
}

Le compilateur vérifie l'exhaustivité du switch : oublier un cas devient une erreur, pas un bug de production trouvé six mois plus tard.

Pourquoi c'est significatif

F#, cousin fonctionnel de C# dans le même écosystème .NET, a les discriminated unions depuis toujours - c'est un des arguments de vente historique du langage. Rust en a fait un pilier de sa conception (les fameux enum et le match). Swift aussi. TypeScript, à sa manière, a les union types depuis 2015. Kotlin a les sealed class qui approchent le pattern. C# arrivait avec du retard - il fallait bricoler des hiérarchies de classes abstraites, des sealed record, des OneOf<T1,T2,T3> en bibliothèque tierce.

Trois conséquences concrètes de cette arrivée :

1. La modélisation métier devient plus honnête. Les états mutuellement exclusifs qu'on représentait par convention deviennent des types. Le compilateur devient un allié pour ne rien oublier.
2. Les bibliothèques comme OneOf et LanguageExt vont se réorganiser. Une partie de ce qu'elles offraient devient natif ; le reste (monades, application partielle) reste utile.
3. La frontière C#/F# se brouille encore un peu plus. F# gardera ses atouts (inférence de type plus poussée, pipeline |>, immutabilité par défaut), mais l'écart se réduit - la question du choix de langage dans un projet .NET se pose différemment.

Ce qu'il faut vérifier avant de foncer

• La syntaxe définitive : Microsoft n'a pas encore publié la spec finale. Les exemples ci-dessus sont illustratifs.
• L'interop : comment les unions C# se sérialisent en JSON, se comportent en Entity Framework, s'exposent en WCF/gRPC. Ces détails détermineront leur adoption réelle.
• La compatibilité : les unions arrivent probablement en C# 14+ avec .NET 10. Les projets sur .NET Framework historiques ou .NET 8 LTS attendront.

À retenir

Les types union en C#, c'est F# qui infuse dans C# - la ligne éditoriale de Mads Torgersen (lead design C#) depuis quelques versions. Pour nos projets, l'intérêt le plus immédiat est la modélisation des résultats d'API (succès/erreur/partial), des états de workflow (brouillon/en révision/publié), et des payloads polymorphes (event sourcing, messages Kafka).

Ce n'est pas révolutionnaire - les autres langages majeurs l'ont depuis 10 ans. Mais pour l'écosystème .NET entreprise, où C# reste le langage dominant en business logic, c'est un saut qualitatif dans la fiabilité du typage. À tester dès la preview de novembre.