Ingénierie·6 min de lecture·mars 2026

Le temps réel, ce que ça coûte vraiment

Latence, files d’attente, mise à l’échelle : le prix d’une application temps réel, et quand un rafraîchissement suffit.

« On veut du temps réel. » La phrase revient dans presque chaque cahier des charges. Elle sonne moderne, elle rassure, et le plus souvent elle n’a jamais été chiffrée. Le temps réel n’est pas une case à cocher, c’est une décision d’architecture qui engage votre budget, votre infrastructure et la fiabilité de votre produit pendant des années. Regardons ce qu’une application temps réel coûte vraiment, et quand elle en vaut la peine.

Le temps réel, en clair

Une application classique fonctionne par requêtes : le navigateur demande, le serveur répond, puis le lien se referme. Pour une information fraîche, il faut redemander. Le temps réel inverse cette logique : le serveur pousse la donnée vers l’écran dès qu’elle change, sans que l’utilisateur ait à rafraîchir. La technique la plus répandue s’appelle le websocket, un canal ouvert en permanence entre l’appareil et le serveur. C’est ce qui fait apparaître un message, un vote ou une position sur une carte chez tout le monde au même instant. Cette synchronisation temps réel est un vrai confort, et c’est aussi là que les coûts commencent.

Le mythe du « live » instantané

Instantané est un mot marketing, pas une réalité physique. Entre deux appareils, une donnée traverse des câbles, des routeurs, parfois un continent. Cette latence, ce délai incompressible, se mesure en dizaines de millisecondes dans le meilleur des cas. Ajoutez le temps de traitement du serveur et la file d’attente des messages en heure de pointe, et le « live » devient un « presque live ». Pour une messagerie ou un tableau de bord, personne ne le remarque. Pour du trading ou du jeu compétitif, ces millisecondes coûtent cher et changent toute la conception. La première question n’est donc pas « peut-on faire du temps réel », mais « quel délai est acceptable pour cet usage ».

Ce que le temps réel coûte vraiment

Ouvrir un canal permanent pour chaque utilisateur a des conséquences très concrètes.

  • La mise à l’échelle. Mille utilisateurs, c’est mille connexions ouvertes en même temps, à maintenir même quand rien ne se passe. Un serveur web ordinaire gère cela mal ; il faut une infrastructure pensée pour, et elle se paie.
  • Les files d’attente. Quand un événement touche tout le monde d’un coup, les messages s’empilent. Sans régulation, la synchronisation temps réel prend du retard, puis décroche.
  • La reprise sur incident. Une connexion tombe, le réseau mobile faiblit, l’onglet se met en veille. Le vrai travail est de resynchroniser proprement, sans doublon ni donnée perdue.
  • L’observabilité. Déboguer un flux permanent est plus difficile qu’une simple requête. Il faut des outils pour voir ce qui circule et comprendre un incident après coup.

C’est exactement le genre de fondations que nous traitons dans nos plateformes et infrastructures : un canal temps réel n’est solide que si la couche en dessous l’est aussi.

Quand un rafraîchissement suffit

La bonne nouvelle, c’est que la plupart des produits n’ont pas besoin d’un vrai temps réel. Un tableau de bord qui se met à jour toutes les dix secondes donne une impression de fraîcheur sans le coût d’un websocket. On appelle cela le polling : l’application redemande à intervalle régulier. C’est simple, prévisible, facile à héberger et à déboguer. Réserver le temps réel aux moments où il apporte une vraie valeur, et se contenter d’un rafraîchissement ailleurs, est souvent la décision la plus mûre d’un projet.

Deux besoins, deux choix

Sur l’application Zou., un groupe vote en temps réel pour choisir une sortie : chacun voit les choix des autres bouger en direct, et c’est tout l’intérêt du produit, donc le canal permanent se justifie pleinement. Sur RackSitter, qui surveille des serveurs, un rafraîchissement régulier des indicateurs suffit largement : personne ne perd de vue une machine parce que la mesure date de cinq secondes. Deux besoins, deux réponses, et dans les deux cas un choix assumé plutôt qu’un réflexe.

Le temps réel n’est ni un gadget ni une évidence : c’est un curseur à régler selon l’usage, avec un coût qu’il vaut mieux connaître avant de s’engager. Bien posé, il rend un produit vivant ; mal posé, il fragilise tout le reste. Si vous hésitez sur le bon niveau pour votre projet, parlons-en.

À lire aussi
L
L'équipe Liminal
Studio de développement
Démarrer un projet →