Un chiffre qui change chez vous et qui apparaît chez eux dans la seconde, sans bouton « actualiser » : c'est ce que le web sait faire depuis longtemps, et ce que la plupart des applications de gestion ne font toujours pas.
Le temps réel n'est pas une case à cocher, c'est une décision par écran. Ce qui doit arriver tout seul, ce qui peut attendre le prochain clic, ce qui ne doit surtout pas bouger sous les doigts de quelqu'un en train de saisir : ce tri-là se fait avant d'ouvrir la moindre bibliothèque.
Je pose ces mécanismes sur mes propres applications depuis des années : un assistant dont la réponse s'écrit mot à mot, des soldes partagés qui se recalculent chez tous les membres d'un groupe, et un jeu multijoueur où deux joueurs voient la même partie à quelques millisecondes près. Les pannes de ce genre de dispositif, je les ai déjà payées avant de vous en parler.
Une connexion ouverte, et c'est le serveur qui parle quand il a quelque chose à dire : Mercure branché sur votre application Symfony, flux d'événements côté navigateur. Chaque abonné reçoit un jeton qui ne couvre que son canal, de sorte qu'un utilisateur ne peut pas écouter les données d'un autre.
Classements, soldes, listes partagées, files de traitement : le serveur envoie un ordre de rafraîchissement, chaque écran ouvert recharge sa propre vue avec ses propres droits. Personne n'a à deviner qui regarde quoi, et un utilisateur ne reçoit jamais le tableau de bord d'un autre.
Quand ça monte aussi vite que ça descend, c'est du WebSocket : messages binaires compacts, un serveur de partie par match, état arbitré côté serveur et jamais par le client. C'est ce qui fait tourner mon jeu multijoueur, joueurs simultanés et triche impossible compris.
Reconnexion automatique, battement de cœur applicatif pour traverser les proxys et le réseau mobile, et surtout une règle simple : la panne du canal temps réel ne doit jamais faire échouer une écriture. Le direct est un bonus, l'application reste utilisable sans lui.
Pronostics sportifs en temps réel
Plateforme gratuite de pronostics entre amis pour la Coupe du Monde 2026 : ligues privées, pronostics sur les 104 matchs, scores et classements en temps réel sans rechargement, jokers, badges et mur de ligue.
Jeu multijoueur temps réel
Jeu de stratégie médiéval multijoueur : client Godot, serveur de match temps réel en WebSocket, matchmaking et backend Symfony. Direction artistique « héraldique flat ».
Assistant juridique par IA
Plateforme privée d'aide à la constitution de dossiers juridiques, assistée par IA : journal de faits horodatés avec pièces, assistant répondant à partir du dossier (RAG), contrôles de confidentialité granulaires. Hébergement en France, données chiffrées.
Oui, et c'est le cas le plus fréquent. Le mécanisme se greffe : un service qui publie côté serveur, quelques lignes côté navigateur, écran par écran. Le seul vrai prérequis est un hébergement qui accepte de garder des connexions ouvertes, ce qu'un mutualisé d'entrée de gamme ne fait pas toujours. Je le vérifie avant de chiffrer, pas après. Sur une application restée en Symfony 3 ou 4, la montée de version vient d'abord : le hub demande un socle récent.
Cela se décide sur le sens du trafic. Si l'information descend du serveur vers l'écran (notification, mise à jour, avancement d'un traitement), Mercure suffit et coûte beaucoup moins cher à exploiter. Si le navigateur doit renvoyer des messages plusieurs fois par seconde, comme dans un jeu ou une édition à plusieurs, c'est du WebSocket. Je choisis au cas par cas, jamais par habitude.
Beaucoup plus que ce que la plupart des projets demandent, à condition de dimensionner. Une connexion ouverte coûte de la mémoire, pas du calcul : c'est le nombre de connexions simultanées qui compte, pas le nombre d'inscrits. Sur mon jeu, la montée en charge est mesurée par un banc d'essai qui ouvre des centaines de connexions et simule les parties, pas estimée au doigt mouillé.
L'application continue, comme une application installable continue de fonctionner hors connexion. Le client se reconnecte tout seul et rattrape ce qu'il a manqué, et toute publication est écrite de façon à ne jamais interrompre le traitement en cours : si le canal temps réel est en panne, la donnée est quand même enregistrée, l'écran est simplement à jour au clic suivant. C'est la différence entre une fonctionnalité confortable et une dépendance critique.
Mon tarif de référence est de 650 € par jour. Ajouter du direct à une application existante se chiffre souvent au forfait, après un cadrage court qui liste les écrans concernés : c'est ce tri-là qui fait le prix, beaucoup plus que la technique employée.
Sous 24 heures, et c'est moi qui réponds. Le premier échange sert surtout à savoir si le temps réel est la bonne réponse : quand un rafraîchissement toutes les trente secondes suffit, je le dis plutôt que d'installer un hub dont vous aurez à vous occuper ensuite.
Décrivez l'écran concerné en quelques lignes : ce qui doit se mettre à jour, pour qui, et à quelle fréquence. Je réponds sous 24 h, avec un avis franc sur ce que le direct apporte chez vous et sur ce qu'il complique.