C’est le Black Friday. Les utilisations se font dans la “War Room”. Le PDG demande : « Combien de revenus avons-nous réalisé au cours des 10 dernières minutes ? » Vous cliquez sur Actualiser. La requête de la base de données prend 15 secondes. La page se charge. “50 000 €.” Au moment où vous le dites, le numéro est faux.

Dans le commerce moderne, les données statiques sont mortes. Mouvements d’inventaire. Les prix changent. Pics de trafic. Les tableaux de bord en temps réel ne sont pas seulement un jouet visuel « agréable à avoir » ; ce sont des outils opérationnels essentiels à la mission. Mais les concevoir correctement (pour des milliers d’utilisateurs simultanés, sans détruire votre base de données) constitue un défi pour les systèmes distribués.

Chez Maison Code Paris, nous construisons des interfaces “Mission Control” qui semblent vivantes. Voici comment procéder sans faire fondre les serveurs.

Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

La bataille des protocoles : sondages, SSE et WebSockets

Le premier transport de données efficace en matière de décision.

1. Sondage (l’approche naïve)

setInterval(() => fetch('/api/sales'), 5000);

Avantages : Simple. Fonctionne sur tous les serveurs (PHP, Node, Python).
Inconvénients :
- Latence : délai moyen de 2,5 s.
- Déchets : 90 % des demandes renvoient “Aucun changement”. Vous martelez votre base de données pour rien.
- Batterie : maintient la radio mobile active.

2. WebSockets (le tuyau bidirectionnel)

Une connexion TCP persistante.

Avantages : Extrêmement rapide. Bidirectionnel (le client peut envoyer « Je suis en train de taper »).
Inconvénients :
- Pare-feu : les proxys d’entreprise bloquent souvent le trafic non HTTP.
- État : la mise à l’échelle est difficile. Vous avez besoin de sessions persistantes ou d’un backend Redis.
- Overkill : un tableau de bord est généralement en lecture seule.

3. Événements envoyés par le serveur (SSE) (la référence)

Connexion HTTP standard, mais le serveur la maintient ouverte et diffuse du texte. « Type de contenu : texte/flux d’événements ».

Avantages :
- Compatible HTTP : fonctionne via des équilibreurs de charge/proxy standard.
- Reconnexion automatique : le navigateur gère automatiquement les tentatives.
- Léger : uniquement des messages texte simples.
Inconvénients : unidirectionnel uniquement (serveur -> client).

Pour les tableaux de bord, SSE est le gagnant technique.

Architecture : Le bus événementiel

Vous ne pouvez pas simplement diffuser de la base de données vers le client. Si vous avez 5 000 clients et que vous exécutez un « SELECT sum(total) FROM commandes » à chaque fois qu’une ligne change, PostgreSQL mourra.

Vous avez besoin d’une architecture de bus d’événements.

Ingérer : Commandez Créer un Webhook -> API.
Publier : API -> Redis Pub/Sub (canal : ventes).
Fan-Out : le serveur SSE s’abonne à Redis.
Diffusion : lorsque Redis émet un message, le serveur SSE parcourt les clients connectés et écrit dans leurs flux.

Code : Le flux Remix / Node.js

Dans un framework moderne comme Remix ou Next.js App Router, le streaming est natif.

// app/routes/api.stream.ts dans Remix
importer { eventStream } depuis "remix-utils/sse/server" ;
importer { redis } depuis "~/lib/redis" ;

exporter le chargeur de fonctions asynchrones ({requête} : LoaderFunctionArgs) {
  return eventStream (request.signal, fonction setup (envoyer) {
    const canal = "mises à jour du tableau de bord" ;

    const écouteur = (message : chaîne) => {
      envoyer({ événement : "mise à jour", données : message });
    } ;

    const abonné = redis.duplicate();
    abonné.subscribe(canal);
    abonné.on("message", (chan, msg) => {
      if (chan === canal) auditeur (msg);
    });

    retourner la fonction cleanup() {
      abonné.unsubscribe(canal);
      abonné.quit();
    } ;
  });
}

Les défis de la connectivité

1. Le problème C10K (mise à l’échelle)

Node.js standard peut gérer environ 10 000 connexions simultanées. Les serveurs comme Apache/PHP ont du mal à en gérer des centaines. Si vous avez besoin de 100 000 utilisateurs connectés (par exemple, un compte à rebours massif pour une vente flash), vous ne pouvez pas utiliser un seul serveur standard. Solution :

Mise à l’échelle horizontale : 10 serveurs derrière un équilibreur de charge.
Fond de panier Redis : chaque serveur s’abonne à Redis. Ainsi, si le serveur A publie, le serveur B le reçoit et le transmet à l’utilisateur B.
Services gérés : pour une évolutivité extrême, transférez vers Pusher ou Supabase Realtime. Ils gèrent la couche socket.

2. Le troupeau tonitruant (Reconnexion)

Vous déployez une nouvelle version du tableau de bord. Le serveur redémarre. 5 000 clients se déconnectent. 5 000 clients tentent immédiatement de se reconnecter à 10h00:01 exactement. Votre processeur atteint 100 %. Le serveur plante. Les clients réessayent. Boucle de la mort. Solution : Gigue. Le client doit attendre « aléatoire (0, 5 000) » millisecondes avant de se reconnecter. L’implémentation SSE native du navigateur présente un recul de base, mais la logique WebSocket personnalisée l’ignore souvent.

3. Limites du descripteur de fichier du système d’exploitation

Un serveur Linux a une limite par défaut de 1024 fichiers ouverts (connexions). Si vous voulez 10 000 utilisateurs, vous DEVEZ modifier /etc/security/limits.conf. * fichier logiciel 100000 * fichier dur nofile 100000 Si vous oubliez cela, votre serveur Node.js plantera avec les erreurs EMFILE chez l’utilisateur #1025.

Réconciliation des États : le fossé

L’utilisateur se trouve dans un tunnel ferroviaire. 10:00:00 - Utilisateur en ligne. Totale : 100 €. 10:00:05 -Tunnel. Utilisateur hors ligne. 10:00:06 - Le serveur pousse l’événement “Nouvelle commande + 50 €”. Le total est désormais de 150 €. 10:00:10 - Fin du tunnel. L’utilisateur se reconnecte.

L’utilisateur estime que le total est de 100 €. Ils ont raté l’événement. L’État dérive.

Correction : Last-Event-ID.

Chaque événement a un identifiant (numéro de séquence ou horodatage).
Le navigateur stocke le dernier identifiant qu’il a vu.
Lors de la reconnexion, le navigateur envoie « Last-Event-ID : 105 ».
Le serveur vérifie son tampon. “Ah, le client est derrière. Voici les événements 106, 107, 108.”

Ou une stratégie plus simple : StaleCheck. À chaque reconnexion, le frontend déclenche un fetch('/api/current-total') HTTP standard pour resynchroniser la ligne de base.

UX : Visualiser le pouls

Les données en temps réel créent un « bruit visuel ». Si vous vendez 10 articles par seconde et que vous mettez à jour le nombre 10 fois par seconde, l’utilisateur ne pourra pas le lire. C’est juste un flou.

Mises à jour des manettes : Limitez les repeintures de l’interface utilisateur à une fois toutes les 500 ms. Accumulez les modifications dans un tampon. Tampon = +10, +5, +20. Flush -> Mettre à jour l’interface utilisateur +35.

Animations : Utilisez framer-motion ou react-spring pour animer le numéro. « 100 » -> « 135 ». L’utilisateur voit les chiffres s’enrouler (comme une pompe à essence). Cela transmet bien mieux la « vitesse » et « l’activité » qu’un saut statique.

function AnimatedNumber({ valeur }) {
  const { nombre } = useSpring({
    de : { numéro : 0 },
    nombre : valeur,
    délai : 200,
    config : { masse : 1, tension : 20, friction : 10 },
  });

  return <animated.span>{number.to((n) => n.toFixed(0))}</animated.span>;
}

10. Sécurité : contrôle d’accès basé sur les rôles (RBAC) sur les flux

L’authentification HTTP standard valide la demande. Mais une fois le socket ouvert, comment empêcher un « Store Manager » d’écouter les événements de vente « Global Admin » ? Étendue des canaux.

L’utilisateur se connecte à JWT.
Le serveur décode JWT -> role: manager, store_id: 12.
Le client demande un abonnement à « sales-global ».
Logique du serveur : if (role !== 'admin') throw Forbidden.
Logique du serveur : « Autoriser uniquement redis.subscribe(‘sales-store-12 »).

11. Granularité des données : tick vs agrégat

Devez-vous émettre un événement pour chaque commande de 5 € ? Si vous avez 100 commandes/sec, votre tableau de bord ressemblera à une lumière stroboscopique. Stratégie d’agrégation :

Raw Stream : Utilisation interne / Débogage.
Flux limité (interface utilisateur) : regroupement toutes les secondes.
- { événements : 50, total_added : 5000 }. *Envoyez un message.
Flux d’instantanés : toutes les minutes. Synchronisation complète. Équilibrez la « sensation en temps réel » avec les « limites cognitives humaines ».

13. La décision « Constructeur vs Acheter » (Grafana)

Parfois, vous n’avez pas besoin de créer un tableau de bord React personnalisé. Si le public est “Ingénieurs” ou “Opérations internes”, utilisez simplement Grafana. Connectez-le à votre réplica en lecture PostgreSQL. Réglez le taux de rafraîchissement sur 5 secondes. Fait. Coûte 0 €. Nous créons des tableaux de bord React personnalisés uniquement lorsque le public est constitué de « clients externes » ou de « cadres de niveau C qui ont besoin d’une UX spécifique ».

14. Seuils d’alerte (repères visuels)

Un nombre passant de 100 à 120 est une donnée. Un nombre passant de 100 à 120 (fond rouge) est une information. Nous intégrons la « logique de seuil » dans les composants frontaux. if (valeur <cible) couleur = 'rouge'. Cela aide les utilisateurs à traiter le flux en temps réel de manière cognitive. “Je n’ai pas besoin de lire les chiffres ; j’ai juste besoin de rechercher Red.”

15. Conclusion

Construire un tableau de bord en temps réel consiste à gérer l’illusion de l’immédiateté. Cela nécessite une danse synchronisée entre la base de données, le bus d’événements, le serveur Web et l’interface utilisateur du client. Mal fait, c’est un goulot d’étranglement en termes de performances. Bien fait, il constitue le cœur de l’organisation.

Vos données sont-elles obsolètes ?

Nous construisons des interfaces de trading haute fréquence pour le commerce de détail. Engagez nos Architectes.