SignalR pour vos notifications ? Vous n'en avez peut-être pas besoin

Par Antoine Rakotomanga · 18 mars 2025 · 5 min de lecture

Temps réel = SignalR. C'est le réflexe. Sauf que dans 80 % des cas, on veut juste envoyer des données du serveur vers le client. Rien d'autre.

Notifications, dashboards, progress bars, feeds d'activité... C'est que du push serveur vers client. Et le client ? Le reste du temps, il appelle votre API REST pour agir. Comme il l'a toujours fait.

Le vrai besoin de bidirectionnel, c'est : chat, jeux multijoueurs, whiteboard collaboratif... Des cas où le client parle autant que le serveur.

La solution native : Server-Sent Events

Si vous avez seulement besoin de passer des infos temps réel du back vers le front, regardez du côté des Server-Sent Events (SSE). C'est natif, c'est léger, et ça fait exactement ça : du push serveur vers client. .NET 10 simplifie en plus son implémentation côté serveur.

Côté back, c'est du HTTP standard : une connexion qui reste ouverte. Vos actions métier poussent des events typés dessus, en async, sans bloquer de thread :

// Un endpoint SSE minimal
app.MapGet("/notifications", async (HttpContext ctx, CancellationToken ct) =>
{
    ctx.Response.Headers.ContentType = "text/event-stream";
    await foreach (var notif in queue.ReadAllAsync(ct))
    {
        await ctx.Response.WriteAsync($"event: {notif.Type}\ndata: {notif.Json}\n\n", ct);
        await ctx.Response.Body.FlushAsync(ct);
    }
});

Côté front, EventSource est natif dans tous les navigateurs modernes, zéro lib à installer. Le front se branche une fois, reçoit, regarde le type, réagit :

const source = new EventSource('/notifications');
source.addEventListener('commande', e => refresh(JSON.parse(e.data)));

Pour vulgariser : c'est comme si vous branchiez une sonnette chez vous. Le livreur sonne, dépose le colis et repart. Vous n'êtes pas bloqué derrière la porte à attendre, et vous savez direct quand vous êtes livré.

SignalR / SSE : le comparatif

SignalR vous donne : bidirectionnel par défaut, lib front obligatoire, fallback auto (WebSocket, SSE, Long Polling), clients mobiles natifs, gestion de groupes.

SSE vous donne : unidirectionnel (serveur vers client), zéro lib, reconnexion native côté navigateur, du HTTP lisible dans vos devtools.

Le trade-off : SSE, c'est web only. Pas d'EventSource natif sur iOS, Android, React Native ou Flutter : libs tierces obligatoires. SignalR propose des clients pour toutes ces plateformes.

Et le scaling ?

SignalR a besoin d'un backplane (Redis, Azure SignalR Service...) pour que vos instances communiquent. SSE a le même « problème ». Mais rien ne vous empêche de brancher votre propre pub/sub (Redis, RabbitMQ...).

Mon retour d'expérience

Perso, j'utilisais toujours SignalR par défaut. Jusqu'à ce que je travaille sur un système de gestion de files d'attente pour l'entrée d'un stade de foot : push des positions en temps réel vers les écrans, zéro besoin que le client réponde. SSE a fait le job, sans la complexité.

À retenir : SSE ne remplace pas SignalR. C'est juste qu'on n'a pas toujours besoin d'un tank pour aller chercher le pain.

Cet article est tiré d'une de mes publications LinkedIn : rejoignez la discussion ↗