Communication & legacy : guide architecture .NET

En clair

Les applications se parlent de plusieurs façons : question-réponse immédiate (REST, gRPC), temps réel où le serveur pousse les nouvelles (SignalR), ou messages déposés dans une boîte aux lettres que le destinataire lira quand il pourra (Pub/Sub). Et beaucoup d'entreprises ont du code ancien qu'il faut moderniser pièce par pièce, comme on rénove une maison en continuant d'y habiter.

Les bases réseau Junior

Résoudre le nom, ouvrir la connexion TCP, négocier TLS, puis échanger. Réutiliser les connexions (keep-alive, IHttpClientFactory) évite de payer ces allers-retours à chaque appel.

Version HTTP	Transport	Apport
HTTP/1.1	TCP	Une requête à la fois par connexion
HTTP/2	TCP	Multiplexage de plusieurs requêtes sur une connexion ; requis par gRPC
HTTP/3	QUIC (UDP)	Pas de blocage en tête de file, meilleur sur réseau mobile ; supporté par Kestrel

Choisir un mode de communication Confirmé

Mode	Format	Pour	Limites
REST / JSON	Texte, lisible	API publiques, navigateurs, partenaires	Contrat moins strict, plus verbeux
gRPC	Protobuf binaire, HTTP/2	Appels entre services internes, streaming	Navigateur seulement via gRPC-Web ; débogage moins direct
SignalR	WebSocket (repli SSE, long polling)	Temps réel : notifications, tableaux de bord, chat	Connexions longues, scale-out à prévoir
GraphQL	JSON, une requête qui choisit ses champs	Front-ends aux besoins variés	Cache HTTP difficile, coût des requêtes à borner
Messages (Pub/Sub, RabbitMQ)	Au choix	Découplage, traitements asynchrones, pics de charge	Cohérence éventuelle, idempotence obligatoire

orders.proto — le contrat gRPC génère client et serveur

syntax = "proto3";
option csharp_namespace = "Shop.Grpc";

service OrderService {
  rpc GetOrder (GetOrderRequest) returns (OrderReply);
  rpc WatchStatus (GetOrderRequest) returns (stream StatusUpdate);   // streaming serveur
}

message GetOrderRequest { string order_id = 1; }
message OrderReply      { string order_id = 1; string status = 2; int64 total_cents = 3; }
message StatusUpdate    { string status = 1; }

Ne renumérotez jamais un champ Protobuf existant : le numéro est le contrat sur le fil. Pour retirer un champ, marquez-le reserved.

SignalR à plusieurs instances

Chaque client est connecté à une seule instance. Pour qu'un message atteigne tous les clients, il faut un backplane (Redis / Memorystore) ou un service managé, et des sessions persistantes (affinité) quand le repli long polling est autorisé. Sur Cloud Run, activer l'affinité de session et dimensionner la durée maximale des requêtes, car une connexion WebSocket compte comme une requête longue.

Moderniser l'existant .NET Framework Senior

Réécrire d'un coup est le chemin le plus risqué. Le pattern strangler fig (figuier étrangleur) place une façade devant l'ancienne appli : chaque route migrée est servie par la nouvelle, le reste continue de partir vers l'ancienne, jusqu'à ce qu'elle soit vide.

Orange : routes déjà migrées. Bleu : tout le reste, relayé tel quel vers l'ancienne appli. Les adaptateurs System.Web permettent de partager session et authentification entre les deux pendant la transition.

Feuille de route de migration

Inventaire : dépendances NuGet sans version .NET moderne, API Windows-only, usages de System.Web, WCF, Remoting, AppDomains.
Projets au format SDK et PackageReference à la place de packages.config, encore sur .NET Framework.
Bibliothèques en netstandard2.0 (ou multi-cible net48;net10.0) : elles servent l'ancien et le nouveau code.
Façade YARP et migration route par route, en commençant par les écrans à forte valeur ou faible risque.
Remplacements : ConfigurationManager → IConfiguration, HttpContext.Current → injection d'IHttpContextAccessor ou paramètres, Global.asax → middleware, HttpModules → middleware.
Retrait de l'ancienne appli quand plus aucune route n'y aboutit (le surveiller par les logs du proxy).

Côté outillage, Microsoft oriente désormais la migration assistée vers la modernisation par GitHub Copilot dans Visual Studio, l'ancien .NET Upgrade Assistant n'étant plus mis en avant. Dans tous les cas, un outil accélère la mécanique, il ne remplace pas l'inventaire ni les tests de non-régression.

Et WCF ?

Situation	Option
Appeler un service WCF existant depuis .NET 10	Packages clients `System.ServiceModel.*` (dotnet-svcutil pour générer le proxy)
Héberger des contrats WCF sur .NET moderne avec un minimum de changements	CoreWCF (open source, soutenu par Microsoft) : BasicHttp, NetTcp, WSHttp et d'autres, sous-ensemble de WCF
Nouveau contrat entre services internes	gRPC
Contrat exposé à des clients variés	API REST + OpenAPI

Piège

Big bang : une réécriture complète gèle les évolutions pendant des mois et rate presque toujours des règles métier implicites.
Comportements cachés : sérialisation (dates, DataContractSerializer vs System.Text.Json), culture par défaut, encodage. Comparer les réponses de l'ancien et du nouveau sur les mêmes entrées.
Timeouts gRPC absents : toujours fixer une deadline sur l'appel, sinon un appel peut attendre indéfiniment.

À retenir

REST pour l'externe, gRPC pour l'interne, SignalR pour le temps réel, messages pour découpler.
Migration progressive derrière une façade YARP, jamais de big bang.
WCF : CoreWCF pour conserver, gRPC ou REST pour les nouveaux contrats.