Cloudflare Stream WebRTC sort de bêta et devient facturable

Cloudflare a ouvert la diffusion WebRTC à très faible latence de Stream à la disponibilité générale le 15 octobre 2026 et a commencé à facturer son utilisation le même jour. Les opérateurs de sites qui utilisaient la bêta doivent vérifier les minutes d'audience facturables avant de supposer que leurs coûts de vidéo en direct restent inchangés.

L'avis de lancement indique que la diffusion WebRTC apparaît désormais dans les analyses de Stream et les graphiques d'utilisation facturable. Le lancement concerne la diffusion d'un émetteur vers plusieurs spectateurs via Stream, pas un service de visioconférence prêt à l'emploi. L'éditeur doit toujours prévoir une expérience de visionnage adaptée à son public.

Comptez les spectateurs autant que la durée d'émission

Les tarifs actuels de Stream affichent 1 dollar américain pour 1 000 minutes diffusées. Ces minutes s'additionnent pour l'ensemble des spectateurs. Une émission hypothétique regardée pendant 20 minutes par 150 personnes représente 3 000 minutes de visionnage, soit 3 dollars américains de diffusion à ce tarif, avant d'autres frais ou conditions contractuelles applicables.

Ce calcul est une estimation, pas un plafond de dépenses. Le nombre de spectateurs et leur durée de visionnage peuvent tous deux différer du programme prévu. Notez les hypothèses avant le direct, puis rapprochez-les de l'utilisation mesurée par le fournisseur plutôt que de la longueur d'un enregistrement.

Si l'événement dispose déjà d'un budget, désignez une personne chargée de contrôler l'utilisation après la diffusion. La disponibilité générale modifie le cadre commercial même lorsque le lecteur vidéo du site semble presque identique.

Faible latence ne signifie pas fonctionnalités vidéo complètes

La documentation WebRTC décrit la lecture dans le navigateur et les logiciels de diffusion pris en charge. Un délai réduit peut compter lorsque les spectateurs réagissent à une action en direct. Il ne remplace toutefois pas la vérification de toute la chaîne de production sur les appareils et les réseaux réellement utilisés par les lecteurs.

Une limite est également explicite : la documentation tarifaire de Cloudflare indique que les émissions WebRTC ne peuvent actuellement pas être enregistrées. Un éditeur qui promet un replay doit donc disposer d'un dispositif d'enregistrement séparé et vérifié. Ne supposez pas qu'un service de diffusion en direct crée automatiquement une archive.

Testez les autorisations du microphone et de la caméra, la reprise de lecture après une interruption de connexion et la page affichée avant le début de la diffusion. Ce sont des critères de validation de votre installation, pas des affirmations selon lesquelles le lancement de Cloudflare les aurait résolus pour tous les sites.

Examinez l'intégration, pas seulement le lecteur

Gardez les identifiants de diffusion hors du code public des pages et limitez les personnes autorisées à démarrer un flux. Confirmez la prise en charge du lecteur et de la méthode d'ingestion choisis, puis documentez une solution de repli pour les spectateurs qui ne peuvent pas se connecter. Une répétition réussie sur un ordinateur portable ne constitue pas tout le test.

Ajoutez ce contrôle de facturation à votre routine de maintenance web. Lorsque vous comparez un service de diffusion hébergé à une infrastructure déjà payée, utilisez les mêmes hypothèses de charge que dans votre évaluation de l'hébergement. La comparaison utile porte sur le coût de l'événement complet, y compris les éléments que Stream ne fournit pas.