Pourquoi nous avons quitté Cloudflare pour le temps réel de Cliqer (et pourquoi nous restons fans)

Le 24 septembre 2026 à 18 h 42 UTC, nous avons migré toutes les connexions Cliqer en direct de Cloudflare Workers et Durable Objects vers nos propres serveurs dédiés. Nous avons essayé l’edge, et cette fois-ci, il nous a fait défaut. Si vous utilisez Cliqer, rien ne change dans votre façon de travailler. Ce qui change se passe en coulisses : vos salles ne redémarrent plus pour des raisons que personne ne sait expliquer.

Cet article en donne la version honnête. C’est aussi un remerciement, car nous sommes toujours clients de Cloudflare et toujours sincèrement fans de ce qu’ils construisent.

Ce que nous voulions construire

Cliqer est un outil du direct. Un présentateur touche son téléphone, et une diapositive avance sur un écran qui se trouve peut-être sur un autre continent. Des intervenants rejoignent une émission, des animateurs changent de source, des minuteurs décomptent sur scène. Tout cela repose sur des WebSockets : des connexions longue durée qui ne doivent jamais flancher, car lorsqu’elles flanchent, c’est devant un public.

Les Durable Objects semblaient parfaitement adaptés. Chaque salle obtient un objet monothread qui détient ses propres sockets et son propre stockage, et qui tourne sur le réseau de Cloudflare. Aucun serveur à gérer, aucune montée en charge à planifier. Fin mai, toutes les salles tournaient dessus, et la passerelle historique Cliqer v1 les a rejointes en juin.

Ce qui a mal tourné

Des redémarrages inexplicables

Un Durable Object peut être redémarré par la plateforme à tout moment, et lorsqu’il redémarre, toutes les WebSockets qu’il détient sont fermées. Sur une fenêtre de 24 heures de logs que nous avons examinée précisément pour cela : aucun socket n’a survécu à un redémarrage. Pas un seul.

Ce serait acceptable si les redémarrages étaient rares. Ils ne l’étaient pas :

• 21 redémarrages en 5 jours pour l’objet de Lisbonne qui hébergeait toutes les salles, dont 4 en une seule heure. Aucun manque de mémoire, aucune limite de CPU atteinte, une poignée d’erreurs internes à la plateforme, et aucun déploiement de notre part.
• Nous l’avons déplacé. Les Durable Objects restent là où ils ont été créés, donc le déplacer revient à le recréer en espérant qu’il atterrisse à un meilleur endroit. Le premier essai a atterri à Madrid, le suivant à Amsterdam.
• À Amsterdam, les redémarrages ont continué, toutes les 2 à 16 heures, soit environ toutes les 8,7 heures en moyenne.
• En septembre, l’objet qui servait les salles historiques redémarrait encore 2 à 5 fois par jour, sans raison. Le 8 septembre à 18 h 53, toutes les connexions historiques se sont fermées dans la même milliseconde. Aucun déploiement, aucun incident sur la page de statut.

Pour vous, chacun de ces redémarrages était un moment où la télécommande de présentation ne répondait plus, où un intervenant disparaissait, ou où l’application indiquait une reconnexion en plein direct.

Un stockage qui expirait et réinitialisait la salle

Entre le 7 et le 10 septembre, nous avons vu le message d’erreur « Durable Object storage operation exceeded timeout which caused object to be reset » 8 fois sur 4 objets. Une tentative de reconnexion a attendu 44,5 secondes avant d’échouer. Une lecture du stockage qui aurait dû prendre quelques millisecondes a emporté toute la salle avec elle.

Chaque déploiement redémarrait toutes les salles

Celui-ci est documenté, et c’est de bonne guerre : publier une nouvelle version d’un Worker redémarre ses Durable Objects, et les redémarrer ferme leurs connexions. Entre le 19 et le 21 août, 44 % des reconnexions dans les salles clients en direct sont survenues par vagues synchronisées, et trois de nos propres mises en production en une seule journée ont coupé toutes les salles, dont une en plein direct.

Nous avons donc isolé les sockets dans leur propre Worker, et construit un outil qui examinait chaque fichier modifié et décidait quels déploiements avaient le droit de toucher aux salles. Cela a fonctionné : la mise en production suivante du site est partie avec cinq animateurs en direct et zéro événement de salle. Mais cela signifiait aussi que toute modification du code temps réel redémarrait encore tout le monde.

Des comportements subtils qui nous ont piégés en direct

• 16 minutes de silence. Le 4 août, 43 sockets sont restés connectés alors qu’aucun message n’était livré à aucune salle. L’edge continuait de répondre aux heartbeats au nom de la salle, si bien qu’aucun client ne savait que quelque chose clochait et que personne ne s’est reconnecté. Cela venait d’une fonctionnalité de la plateforme que nous venions d’adopter, combinée à notre propre logique de suivi. Nous l’avons retirée la même semaine.
• Des animateurs fantômes. Les événements de fermeture ne sont pas garantis d’atteindre un objet en veille, si bien qu’un animateur parti pouvait sembler connecté pendant des heures.
• Une URL en cache bloquée pendant quatre heures. En août, une couche de cache devant notre Worker s’est bloquée sur la seule URL que l’application de bureau consulte au démarrage. L’application ne pouvait plus démarrer. La même URL avec un paramètre bidon répondait en une seconde.

Ce que nous avons construit pour tenir le coup

En quatre mois, nous avons construit environ 18 mécanismes distincts pour vous masquer la plateforme : des heartbeats plus rapides, des balayages pour les animateurs fantômes, des registres reconstruits depuis le stockage à chaque réveil, des identités qui survivent à un redémarrage pour que vos applications puissent reprendre, un Worker de sockets séparé, un classificateur de déploiements couvrant 161 fichiers, des re-tirages du placement, un chien de garde pour le relais, un sharding par salle et un registre des places inter-shards pour l’accompagner.

Nous en avons ensuite supprimé trois, car ils causaient plus de problèmes qu’ils n’en résolvaient. Et chaque contournement ajoutait des pièces mobiles. Répartir les salles sur plusieurs objets nous a valu une salle rebelle qui répondait pour le mauvais shard, un spectateur coincé dans une boucle de relocalisation, et une limite de places contournable d’un shard à l’autre. Chaque problème a été corrigé, mais nous passions notre temps à contourner la plateforme au lieu de construire Cliqer.

Soyons justes

Toutes les connexions coupées pendant ces mois n’étaient pas imputables à Cloudflare. Nous avons vérifié :

• 86 % des reconnexions individuelles concernaient des appareils isolés lâchés par leur propre réseau : proxys d’entreprise, Wi-Fi des lieux d’événement, pare-feu qui n’aiment pas les connexions longues. C’est pourquoi nous avons livré la prise en charge des réseaux d’entreprise dans l’application de bureau en août.
• Certaines vagues provenaient de nos propres déploiements, et quelques-unes de nos propres outils de débogage.
• Nous n’avons jamais ouvert de ticket de support au sujet des redémarrages. C’est notre faute.

Les Durable Objects sont une prouesse d’ingénierie, et pour de nombreux usages, ils sont exactement ce qu’il faut. Une salle qui ne doit jamais flancher, devant un public en direct, s’est révélée être le pire scénario pour une plateforme capable de la redémarrer à tout moment. Nous avons essayé l’edge pour le temps réel, et cette fois-ci, il nous a fait défaut. C’est un verdict sur cet usage, pas sur l’edge.

Ce qui fait tourner vos salles aujourd’hui

Le temps réel de Cliqer tourne désormais sur nos propres serveurs dédiés. Ils servent le site web, l’API et chaque WebSocket, et hébergent directement toutes les salles, avec une base de données locale. Le trafic passe toujours par le réseau de Cloudflare, vous conservez donc la même protection et les mêmes adresses.

Ce qui a disparu :

• Plus de redémarrages à notre insu. Le processus tourne jusqu’à ce que nous en décidions autrement.
• Plus de loterie du placement, et plus d’expirations du stockage qui réinitialisent les salles.
• Plus de sharding. Une salle, un endroit, une seule source de vérité.

Ce que nous assumons en toute transparence :

• Lorsque nous publions une mise à jour, votre connexion se reconnecte une fois. La nouvelle version démarre à côté de l’ancienne et prend le relais presque instantanément. Vos applications se reconnectent en une seconde environ avec la même identité et reprennent là où elles en étaient. Lors de notre répétition, 4 757 requêtes web ont traversé la bascule et aucune n’a échoué.
• Nos serveurs sont en Europe. Nous préférons exploiter des machines que nous comprenons parfaitement plutôt que des centaines d’emplacements dans lesquels nous n’avons aucune visibilité.

Plus rapide, en plus

Nous enregistrons la durée de chaque requête API de notre côté, ce qui nous permet de comparer la semaine précédant la migration avec les jours suivants, sur du trafic réel plutôt qu’en laboratoire.

Les requêtes les plus lentes se sont encore davantage améliorées. Le décile le plus lent des chargements de l’habillage du tableau de bord est passé de 1,7 seconde à moins d’une demi-seconde, et les récupérations d’identifiants de relais les plus lentes sont devenues 7 fois plus rapides.

Le plus gros changement est celui que vous ressentez en premier. Une connexion temps réel restée inactive sur l’ancienne plateforme mettait environ 1,2 seconde à s’ouvrir, le temps de se réveiller. Sur notre propre serveur, elle s’ouvre en environ 0,14 seconde, à chaque fois. Notre outil indépendant de surveillance de disponibilité, qui vérifie cliqer.io chaque minute depuis l’Amérique du Nord, raconte la même histoire : environ 750 ms par vérification avant la migration, environ 380 ms après.

Dans une salle, les clics étaient déjà rapides et ils le sont toujours. Ce qui a changé, c’est tout ce qui les entoure : ouvrir l’application, charger la page présentateur, récupérer votre compte. Tout répond plus vite, et de la même façon à chaque fois.

Ce que Cloudflare fait encore pour nous

Beaucoup de choses, et avec plaisir :

Leurs outils d’observabilité et d’analyse ont aussi rendu possible l’essentiel du diagnostic présenté dans cet article. Nous sommes toujours clients, et nous les recommandons toujours.

Si quelque chose coupe, dites-le-nous

Notre promesse est simple : désormais, lorsqu’une connexion tombe, il y a une raison que nous pouvons identifier. Si vous voyez un jour Cliqer se reconnecter en plein direct (et voici que faire quand les diapositives se figent sur le moment), répondez à n’importe lequel de nos e-mails ou ouvrez une discussion depuis l’application. Nous lisons chaque message, et maintenant, nous pouvons vraiment vous dire pourquoi.