Du temps réel sans toute la machinerie habituelle
Faire évoluer un contenu en direct pour des centaines de personnes demande, d'habitude, une infrastructure lourde. En partant d'une simple question, j'ai trouvé une approche radicalement plus simple.
Tout est parti d’une question simple, en construisant une application collaborative : comment faire du temps réel ? Comment des centaines de personnes peuvent voir, sur la même page, un contenu évoluer en direct — un sondage qui se remplit, un tableau qui bouge, un jeu partagé.
La réponse que tout le monde donne depuis dix ans, je la connaissais. Mais en cherchant, je suis tombé sur un article décrivant une technologie récente de Cloudflare : les Durable Objects. Et ça a tout changé.
La recette habituelle, et son problème
Pour faire du temps réel, il faut une « salle » technique où tout le monde est connecté en même temps. La méthode classique, c’est de faire tourner plusieurs serveurs en permanence, plus un système central pour les faire communiquer entre eux. C’est solide, c’est éprouvé — beaucoup de grandes applications ont commencé comme ça.
Mais quand je regarde tout ce que ça demande, ce qui me frappe, c’est la lourdeur. Plusieurs serveurs à installer, à surveiller, à garder debout en permanence. Un système central à maintenir pour les coordonner. Toute une mécanique à faire tenir ensemble — et plus il y a de pièces, plus il y a d’endroits où ça peut casser. Tout ça pour un besoin qui, au fond, est simple.
Et justement, cette mécanique ne correspondait pas à mon besoin. Mon besoin ressemblait plutôt à ça : quelques dizaines ou centaines de personnes qui partagent un moment pendant une heure ou deux, puis tout le monde repart.
La question que je me suis vraiment posée
Alors plutôt que « comment faire tenir cette grosse machinerie ? », j’ai fini par me poser une question plus bête : et si je n’avais pas besoin de tout ça ?
C’est exactement ce que permettent les Durable Objects. Au lieu d’une grande infrastructure partagée, on crée une petite salle dédiée à chaque session. Tous ceux qui rejoignent la même session arrivent dans la même salle — et il n’y en a qu’une. Plus de serveurs à coordonner, plus de système central à maintenir : la salle elle-même suffit. Une seule pièce, au lieu de tout un échafaudage.
Le détail qui change tout : la mise en veille
À ce stade, je me suis dit : une salle par session, ça fait beaucoup de salles à gérer. Mille sessions, mille serveurs à surveiller ?
Eh bien non. Ces salles ont une particularité qui m’a bluffé : elles se mettent en veille toutes seules dès qu’il ne se passe rien, sans déconnecter personne. Les participants restent connectés, mais tant que c’est silencieux, la salle ne mobilise plus aucune ressource. Au moindre mouvement, elle se réveille en quelques millisecondes.
Concrètement, plus rien ne tourne à vide. C’est l’inverse de l’approche classique, où les serveurs continuent de mouliner même quand personne ne fait rien.
Ce que ça change vraiment
Ce qui m’a convaincu, au fond, ce n’est pas une histoire de performance. C’est la simplicité. Plus de mécanique à maintenir, plus de système central à surveiller, plus de coordination entre serveurs à débuguer. Une session, c’est une salle, une responsabilité, un état. Quand la session est finie, la salle disparaît.
C’est moins souple qu’une grosse infrastructure, je le reconnais. Mais c’est infiniment plus simple à raisonner, à débuguer, et à faire tenir dans le temps. Et la simplicité, sur un projet, c’est précieux : c’est autant de choses en moins qui peuvent mal tourner.
Ce n’est pas magique non plus
Cette approche a ses limites, et autant être honnête. Elle lie le projet à l’écosystème Cloudflare. Et cette technologie est encore jeune : moins d’exemples, moins de réponses toutes faites en ligne, on défriche un peu plus qu’avec les méthodes établies. Pour des besoins très spécifiques, la recette classique reste parfois la plus adaptée.
Mais dans mon cas — des sessions collaboratives qui vivent quelques heures puis s’éteignent — tout mis bout à bout, le compromis penchait nettement du bon côté.
Ce que je retiens
La recette par défaut résout un problème de mise à l’échelle que beaucoup de projets n’ont pas. Avant d’empiler une infrastructure lourde « parce que c’est comme ça qu’on fait », ça vaut la peine de se demander ce dont on a réellement besoin. Souvent, la réponse est plus simple — et une solution plus simple, c’est une solution qui tient.
Le temps réel ne demande pas toujours une machinerie de géant. Parfois, il demande juste un petit objet, au bon endroit, avec la bonne durée de vie.