C# et .NET pour les applications financières

Sur de nombreux étages sell-side, la tarification, le risque, les OMS, et les clients lourds tournent encore sur C# / .NET — pas parce que personne n'a appris Go, mais parce que des décennies de contrôles, de fournisseurs, et de glu Excel pointent vers cette technologie.

Le .NET moderne est multiplateforme, compétitif en JIT pour de nombreuses charges de travail, et le GC devient de plus en plus discret sur les pauses — important quand une interface de bureau ne peut pas geler pendant une impression chargée.

C# lui-même a intégré le pattern matching, les records, les types de référence nullables, et d'autres fonctionnalités de confort sans abandonner le typage statique — pratique quand une mauvaise refactorisation peut frapper un bilan.

C# offre plusieurs fonctionnalités qui le rendent exceptionnellement bien adapté au calcul financier :

LINQ (Language Integrated Query) permet d'interroger des collections avec une syntaxe proche de SQL directement dans votre code. Traiter un portefeuille de 10 000 positions pour trouver celles qui dépassent les limites de risque devient une seule expression lisible :

var breaches = positions
    .Where(p => p.Notional > riskLimit)
    .OrderByDescending(p => p.Notional)
    .Select(p => new { p.Symbol, p.Notional, p.PnL })
    .ToList();

Async/await — C# a été pionnier du modèle async/await (adopté plus tard par JavaScript, Python, et Rust). Pour les systèmes de trading qui doivent simultanément diffuser des données de marché, traiter les entrées utilisateur, et envoyer des ordres aux plateformes, async/await permet la concurrence sans la complexité de la gestion manuelle des threads.

Le pattern matching (amélioré dans C# 11/12) gère proprement la logique conditionnelle complexe — essentiel pour les règles de routage d'ordres, la classification de risque, et le dispatch par type d'instrument :

decimal CalculateMargin(Instrument inst) => inst switch
{
    { Type: "perpetual", Leverage: > 10 } => inst.Notional * 0.10m,
    { Type: "perpetual" }                => inst.Notional * 0.05m,
    { Type: "spot" }                     => inst.Notional,
    _ => throw new ArgumentException($"Unknown type: {inst.Type}")
};

L'écosystème .NET offre des bibliothèques mûres pour la finance quantitative, de la tarification des dérivés à l'exécution de simulations de Monte Carlo :

Math.NET Numerics est la bibliothèque numérique fondamentale — algèbre linéaire, statistiques, distributions, interpolation, et optimisation. C'est l'équivalent .NET de NumPy/SciPy, avec des moteurs accélérés matériellement (MKL, OpenBLAS) pour les opérations matricielles. Calculer la matrice de covariance d'un portefeuille de 500 actifs ? Math.NET s'en charge avec des routines adossées à LAPACK.

QuantLib.NET enveloppe la bibliothèque QuantLib C++, référence de l'industrie, fournissant des modèles de tarification pour les obligations, les swaps, les options (Black-Scholes, Heston, volatilité locale), et la construction de courbes de taux. Les hedge funds utilisent QuantLib pour tarifer des dérivés exotiques ; le wrapper .NET permet aux applications C# d'appeler ces modèles sans passer par du code non managé.

L'intégration Excel reste cruciale sur les salles de trading. Excel-DNA permet d'écrire des compléments Excel en C# qui apparaissent comme des fonctions natives de feuille de calcul. Un quant peut écrire une fonction de tarification en C#, l'exposer à Excel, et les traders l'utilisent dans leurs tableurs sans connaître ni se soucier de l'implémentation sous-jacente. Ce schéma — moteur C#, interface Excel — est le flux de travail standard sur la plupart des salles sell-side.

[ExcelFunction(Description = "Black-Scholes call price")]
public static double BSCall(double S, double K, double T,
                            double r, double sigma)
{
    double d1 = (Math.Log(S / K) + (r + 0.5 * sigma * sigma) * T)
                / (sigma * Math.Sqrt(T));
    double d2 = d1 - sigma * Math.Sqrt(T);
    return S * NormCdf(d1) - K * Math.Exp(-r * T) * NormCdf(d2);
}

Pour l'analytique de portefeuille et la gestion du risque, les applications C# calculent régulièrement la valeur à risque (VaR), les Grecs (delta, gamma, vega), l'analyse de scénarios, et les tests de stress sur des milliers de positions — des tâches qui exigent à la fois précision numérique et temps de réponse inférieur à la seconde.

Le .NET moderne a comblé une grande partie de l'écart de performance avec C et C++ grâce aux primitives de programmation sans allocation. Span<T> et Memory<T> fournissent un accès sûr et vérifié aux limites de régions mémoire contiguës — tableaux alloués sur la pile, tableaux sur le tas, ou même mémoire non managée — sans allouer sur le tas géré par le garbage collector.

Pour un système de trading qui traite 100 000 messages de données de marché par seconde, chaque allocation sur le tas crée une pression sur le GC. En analysant les messages en tranches Span<byte> plutôt qu'en allouant des objets string, vous pouvez traiter les données de marché avec zéro allocation par message — une technique utilisée en production par des sociétés de trading haute fréquence tournant sur .NET.

// Analyser un prix depuis un message binaire sans allouer
static decimal ParsePrice(ReadOnlySpan<byte> message)
{
    // Découper les octets pertinents, interpréter en point fixe
    var priceBytes = message.Slice(offset: 16, length: 8);
    long rawPrice = BinaryPrimitives.ReadInt64LittleEndian(priceBytes);
    return rawPrice / 100_000_000m; // 8 décimales
}

System.IO.Pipelines étend cette approche aux entrées/sorties réseau, en fournissant un pipeline haute performance pour lire et écrire des flux de données sans copies de buffer. Kestrel, le serveur web d'ASP.NET, utilise Pipelines en interne et gère des millions de requêtes par seconde — ce qui le rend viable pour des points de terminaison API temps réel diffusant des données de trading.

SignalR, construit sur ASP.NET Core, fournit une communication bidirectionnelle en temps réel via WebSockets avec repli automatique vers Server-Sent Events ou le long polling. Pour les applications de trading, SignalR pousse les ticks de prix en direct, les mises à jour d'ordres, et les changements de portefeuille vers les clients connectés avec une latence minimale — semblable à la façon dont GaiaEx diffuse les données de marché en temps réel vers son interface web.

Le terminal de trading — une application de bureau dense et riche en données affichant carnets d'ordres, graphiques, positions, blotters, et métriques de risque — est une application C#/WPF dans la plupart des banques depuis plus d'une décennie. WPF (Windows Presentation Foundation) fournit un rendu accéléré matériellement, une liaison de données puissante, et la capacité d'afficher des dizaines de milliers de cellules en mise à jour sans geler le thread d'interface utilisateur.

Une architecture typique d'interface de trading utilise le patron MVVM (Model-View-ViewModel) : la View est du balisage XAML définissant la mise en page, le ViewModel expose des propriétés observables auxquelles la View se lie, et le Model représente le domaine (positions, ordres, instruments). Quand un prix évolue, le ViewModel met à jour une propriété, le moteur de liaison de WPF propage le changement vers la View, et la cellule se met à jour — tout cela sans que le développeur écrive de code de mise à jour d'interface.

.NET MAUI (Multi-platform App UI) étend ce modèle au développement multiplateforme — Windows, macOS, iOS, et Android depuis une seule base de code C#. Bien que les salles de trading institutionnelles restent dominées par Windows, les plateformes de trading retail ont de plus en plus besoin d'un support mobile et macOS. MAUI offre cette portée sans réécrire la logique métier.

Pour les plateformes de trading hébergées dans le cloud, Blazor offre une alternative convaincante : écrire toute votre interface web en C# au lieu de JavaScript. Blazor WebAssembly exécute C# directement dans le navigateur via WASM, tandis que Blazor Server exécute la logique d'interface côté serveur et envoie les diffs du DOM via une connexion SignalR. Pour une entreprise dont toute la pile est .NET, Blazor élimine le besoin d'une équipe frontend séparée écrivant du React ou de l'Angular.

Le paysage de carrière pour les développeurs C#/.NET en finance est vaste et bien rémunéré :

• Citadel / Citadel Securities — Utilise C# de façon extensive pour les systèmes de trading, les moteurs de risque, et les outils internes. La pile du géant du trading systématique mélange C++, Python, et C#.
• Two Sigma — Emploie C# pour les systèmes de gestion de portefeuille et l'infrastructure de données, aux côtés de Java et Python.
• Bloomberg — L'infrastructure côté serveur du Bloomberg Terminal comprend des composants C# significatifs pour l'analytique et le traitement des données.
• Jump Trading, IMC, Optiver — Les sociétés de trading propriétaire utilisent C# pour les frameworks de développement de stratégies, les moteurs de backtesting, et l'outillage opérationnel.

L'écosystème .NET s'intègre aussi parfaitement avec Azure pour les charges de travail financières basées sur le cloud. Azure Functions fournit du calcul sans serveur pour les calculs de risque par lots. Azure Event Hubs traite des millions d'événements de données de marché par seconde. Azure Kubernetes Service (AKS) orchestre des microservices .NET conteneurisés. La combinaison .NET + Azure est la pile cloud d'entreprise pour les institutions financières régulées qui exigent une conformité SOC 2 et des garanties de résidence des données.

Que vous construisiez un moteur de risque pour une prop shop, un service de tarification pour une plateforme crypto comme GaiaEx, un complément Excel pour une salle de trading, ou un tableau de bord temps réel pour le suivi de portefeuille, C# et .NET vous donnent la performance, les bibliothèques, et la confiance de l'industrie que le poste exige. En finance, où le coût des bugs se mesure en dollars, la sécurité de type, l'outillage, et le runtime éprouvé de .NET ne sont pas des luxes — ce sont des exigences.