Dans le web traditionnel, tout est simple : le client demande, le serveur répond, et la connexion se coupe. C’est le cycle classique du HTTP. Mais que se passe-t-il quand les données côté serveur changent après le chargement de la page ?

Imaginez un tableau de bord boursier, une application de chat ou un outil de gestion des domaines forestiers. Si l’utilisateur doit sans cesse appuyer sur F5 pour voir les dernières informations, l’expérience devient vite frustrante.

C’est là que le temps réel fait toute la différence. Aujourd’hui, nous partons à la découverte de SignalR, la solution d’ASP.NET Core qui transforme la communication web. Grâce à SignalR, une page statique devient vivante : les données s’actualisent automatiquement et l’expérience utilisateur devient fluide et instantanée.

Pourquoi le besoin de temps réel ?

Le web étant sans état (stateless), le client doit sans cesse demander au serveur : « Y a-t-il du nouveau ? ». C’est un peu comme frapper à la porte d’une maison toutes les cinq minutes pour vérifier si quelqu’un est rentré : inefficace et épuisant pour tout le monde.

La méthode Push change la donne : le serveur envoie directement dès qu’il y a du nouveau.

Résultat : le client est informé (presque) instantanément, sans consommation inutile de ressources.

Exemple concret : la salle d’attente virtuelle

Imaginez une file d’attente en ligne pour acheter des billets de concert :

• Sans temps réel : vous rafraichissez la page toutes les 10 secondes. Le serveur reçoit alors des milliers de requêtes inutiles.
• Avec temps réel : votre navigateur reste connecté en permanence. Dès que c’est votre tour, le serveur envoie un signal qui permet à l’application côté front de mettre à jour votre écran instantanément.

SignalR : l’orchestrateur de la communication en temps réel

SignalR, la bibliothèque open-source de Microsoft, simplifie l’intégration de fonctionnalités en temps réel dans les applications .NET. Elle crée un canal de communication bidirectionnel entre un serveur et des clients, permettant au serveur d’envoyer des mises à jour instantanées sans attendre de requête.

Avec SignalR :

• les connexions persistantes deviennent simples à gérer.
• Le code serveur (C#) peut appeler (invoquer) des méthodes JavaScript côté client, et vice-versa.
• Le mode de transport le plus performant est choisi automatiquement selon ce que le serveur et le client supportent.

Les modes de transport :

SignalR facilite cette communication temps réel en gérant automatiquement le meilleur mode de transmission selon le navigateur et le réseau, sans que le développeur ait à changer une seule ligne de code.

Le mode idéal est WebSockets, qui offre une connexion bidirectionnelle et persistante sur une seule connexion TCP. C’est le mode par défaut et le plus performant.

Si les WebSockets sont bloqués, par exemple par un pare-feu d’entreprise, SignalR se rabat sur les Server-Sent Events (SSE). Dans ce cas, le serveur peut pousser des données au client via une connexion HTTP longue durée. La communication est unidirectionnelle (serveur -> client), et le client doit effectuer une requête séparée pour envoyer des données.

Enfin, lorsque les deux solutions précédentes ne sont pas possibles, SignalR utilise le Long Polling. Le client envoie une requête « technique » que le serveur garde ouverte jusqu’à ce qu’une donnée soit disponible. Une fois la donnée envoyée, la connexion se ferme et le client en ouvre immédiatement une nouvelle. Cette méthode fonctionne partout, mais elle est plus gourmande en ressources et légèrement plus lente.

Focus sur les WebSockets dans SignalR

La force de SignalR tient à sa capacité à créer des communications en temps réel ultra-performantes grâce aux WebSockets. Contrairement au HTTP classique, où chaque requête transporte des cookies et des en-têtes lourds, le WebSocket ouvre un canal léger et persistant, idéal pour les échanges fréquents.

Dans une architecture SignalR typique :

• Le Hub (côté serveur) : c’est le cœur de l’application. Il gère les connexions, les groupes et la diffusion des messages.
• Le Proxy client (côté navigateur) : SignalR génère un proxy JavaScript qui facilite la communication avec le Hub et rend les échanges temps réel simples à implémenter.

Grâce à cette approche, les applications web peuvent réagir instantanément, offrant une expérience utilisateur fluide et réactive.

Cas d'utilisation concret : Le Tableau Collaboratif (RowShare)

Pour illustrer la puissance de SignalR, prenons l'exemple de RowShare. C'est un outil de tableaux collaboratifs qui permet à plusieurs utilisateurs de travailler sur la même ligne ou le même tableau simultanément, un peu comme Excel mais avec une gestion fine des droits d'accès. 

Le défi de la collaboration en temps réel
Dans un tableau collaboratif, la cohérence des données est cruciale.
Imaginez ceci : 

1. L'utilisateur A modifie la cellule B2 pour écrire « Budget validé ». 
2. L'utilisateur B, à 500 km de là, regarde la même ligne sur son écran. 

Si l'application attendait que B rafraîchisse sa page pour voir les changements, il pourrait saisir une information contradictoire, comme « Budget refusé ».  

• Résultat : conflit de version. 

La solution : SignalR et WebSocket 

RowShare utilise ces technologies pour synchroniser l'interface en temps réel.

Cas d'usage numéro 1 : un utilisateur entre en saisie sur une donnée partagée 

1. Connexion : quand A et B ouvrent le tableau dans leur navigateur respectif, une connexion WebSocket est établie via SignalR avec le Hub serveur RowShare. Ils rejoignent un « Groupe SignalR » spécifique à l'Id de ce tableau. 
2. Action : L'utilisateur A commence à saisir quelque chose dans une cellule. 
3. Transmission : L'événement est envoyé au Hub RTC RowShare (via la connexion WebSocket ouverte). 
4. Diffusion (Broadcast) : le Hub diffuse un message à tous les membres du « Groupe du tableau » : EnterCell(Row:2, Col:B). 
5. Réception : le code front-end de l'utilisateur B reçoit l'événement et met à jour le DOM (l'affichage) pour verrouiller la ligne 2 et indiquer que sa cellule B est en cours d'édition par un autre utilisateur, sans recharger la page.  L'utilisateur B ne peut pas saisir en même temps une information dans la ligne 2. 

Cas d'usage numéro 2 : un utilisateur valide sa saisie d'une donnée partagée 

1. Connexion : quand A et B ouvrent le tableau dans leur navigateur respectif, une connexion WebSocket est établie via SignalR avec le Hub serveur RowShare. Ils rejoignent un « Groupe SignalR » spécifique à l'Id de ce tableau. 

1. Action : l'utilisateur A a saisi et validé sa valeur dans une cellule. 

1. Validation : la webAPI du serveur RowShare valide et enregistre la donnée. 

1. Transmission : l'événement CellUpdate est envoyé par le serveur RowShare au Hub via sa propre connexion WebSocket. 

1. Diffusion (Broadcast) : le Hub diffuse le message à tous les membres du « Groupe du tableau » : UpdateCell(Row:2, Col:B, Value: »Budget validé »). 

1. Réception : le code front-end de l'utilisateur B reçoit l'ordre et met à jour le DOM (l'affichage) instantanément, sans recharger la page : la cellule affiche maintenant « Budget validé » à tous les utilisateurs. 

Résultat : une collaboration fluide, sans risque de conflit, même à distance. 

Conclusion

Performant, fiable et collaboratif, SignalR transforme vos tableaux de bord et outils collaboratifs en expériences réactives. La référence .NET pour des applications modernes qui connectent vos utilisateurs instantanément.