Quand 4 000 collaborateurs rejoignent le même all-hands au même instant, quelqu’un paie quelqu’un pour ces octets. Ce quelqu’un, c’est en général un abonnement Microsoft Stream, Zoom Webinar, Vimeo Enterprise ou Brightcove : les octets quittent brièvement le réseau de l’entreprise, rebondissent sur un datacenter tiers et reviennent sur le même réseau via une autre connexion. Le PDG est dans une salle de réunion à deux portes de là, et la vidéo qui le montre passe par Francfort avant de revenir.
Ça fonctionne très bien jusqu’au moment où quelqu’un pose la question qui n’a pas vraiment de bonne réponse. “Pourquoi le trafic de notre town hall interne transite-t-il par un SaaS tiers ?” La conformité la pose avant un audit dans une industrie réglementée. La sécurité la pose après chaque divulgation de fuite mentionnant un fournisseur de streaming. Le directeur financier la pose au moment du renouvellement de la facture SaaS au spectateur. La DSI la pose la première fois que le lien WAN du bâtiment sature parce que l’all-hands a battu un record d’affluence.
La réponse honnête, c’est que le live d’entreprise s’est construit autour des encodeurs RTMP et des plateformes SaaS parce que les alternatives étaient soit coûteuses (vidéo d’entreprise Cisco, appliances eCDN Kollective et Hive, équipements CDN internes), soit artisanales d’une manière qu’aucune équipe IT classique n’avait les moyens de maintenir. Les entreprises ont choisi le SaaS parce que rien d’autre n’était à portée.
Ça a changé. L’encodeur, le transcodeur, le packager et l’outil de publication se sont fondus dans un seul logiciel qui tourne sur un Mac. La destination n’a plus besoin d’être un fournisseur. Pointé vers un serveur web à l’intérieur de votre pare-feu, le même logiciel produit du HLS aux standards de la diffusion broadcast, que vos collaborateurs lisent en streaming sur le LAN de l’entreprise, et rien ne sort du réseau.
Cet article explique exactement comment faire.
À quoi ressemble vraiment le “live interne d’entreprise”
La vidéo interne d’une entreprise typique se range dans une courte liste de cas d’usage récurrents.
All-hands trimestriels et town halls du PDG. Audiences importantes (souvent toute l’entreprise), faible fréquence (de quatre à douze fois par an), production modeste. La tolérance à la latence est large : quinze à trente secondes suffisent, parce qu’il n’y a pas d’interaction bidirectionnelle pendant la présentation, et que le Q&A est géré dans un canal séparé.
Sessions de formation et cours de certification. Parfois en direct, souvent revus en différé. Quelques centaines de spectateurs simultanés au maximum. Production minimale : une caméra, un intervenant, des slides partagées depuis un ordinateur portable.
Lancements produit et annonces techniques. Strictement internes parce que l’annonce s’adresse aux équipes avant la presse. Sensibles aux fuites.
Briefings conformité et RH. Formation annuelle à l’éthique, mises à jour réglementaires, hygiène et sécurité. La traçabilité d’audit prime sur la qualité de production.
Mises à jour d’incidents de sécurité. Internes par défaut, parce que le contenu, ce sont les détails de l’incident. Ça doit rester à l’intérieur.
Dans chacun de ces cas, le public, ce sont des collaborateurs internes connectés au réseau de l’entreprise ou au VPN. Le contenu est interne par politique. Envoyer les octets vers un SaaS, faire en sorte que ce SaaS les renvoie à vos collaborateurs, payer à la minute, et demander aux juristes d’ajouter encore un accord de sous-traitance des données : c’est le chemin de moindre résistance, pas la bonne architecture.
À quoi ressemble une alternative on-prem en 2025
L’architecture est suffisamment simple pour tenir sur un Post-it.
Un Mac dans la salle de réunion. Le MacBook de l’intervenant, une caméra USB, le système AV du bâtiment qui injecte l’audio dans le Mac, ou n’importe quelle combinaison de tout ça. Apple silicon dispose d’un encodeur matériel H.264, HEVC et AV1 identique à celui qu’utilise Final Cut Pro pour l’export. Encoder simultanément du 1080p à 5 Mbps, du 720p à 3 Mbps et du 540p à 1.8 Mbps, en temps réel : c’est précisément ce pour quoi la puce a été conçue.
Un serveur web à l’intérieur du pare-feu. N’importe
quoi qui accepte HTTPS PUT et qui sert des fichiers. Un serveur de
fichiers reconverti, une petite VM Linux, un IIS ou un nginx interne
déjà en place pour servir l’intranet. Le point de terminaison reçoit de
petits segments fragmented MP4 (six secondes chacun) et de minuscules
fichiers de playlist .m3u8. Le stockage est négligeable :
une heure de diffusion en trois qualités utilise environ 4 GB. Le
serveur ne transcode pas, ne réempaquette pas, il se contente de stocker
et de servir.
Un lecteur HLS embarqué dans la page intranet. N’importe quel lecteur HLS moderne fait l’affaire : hls.js pour les navigateurs sans HLS natif, le support intégré de Safari, l’Apple TV de la cafétéria, les systèmes d’affichage des salles de réunion que la plupart des entreprises ont déjà.
Voilà toute l’architecture. Les octets ne quittent jamais le réseau. Pas de serveur de streaming à licencier, pas de transcodeur cloud à facturer, pas d’agent eCDN à installer sur chaque ordinateur portable, pas d’abonnement SaaS. Le Mac fait tourner My Live TV Channel, qui encode le flux et le téléverse. Le serveur web que vous avez déjà fait le reste.
Pourquoi ça passe à l’échelle sur un LAN d’entreprise
La première réaction des équipes infrastructure, c’est généralement qu’un seul serveur web ne peut pas absorber l’audience d’un town hall. Sur l’internet public, l’intuition est juste. Sur un LAN d’entreprise, elle ne l’est pas.
Une variante HLS 1080p à 5 Mbps sur un lien montant 1 Gbps sature à environ 200 spectateurs simultanés (1000 ÷ 5). Le même lien à 10 Gbps porte environ 2 000 spectateurs simultanés en 1080p. La variante 720p à 3 Mbps fait passer ces chiffres à environ 333 et 3 300 respectivement. Dans une échelle de débits adaptative, où les spectateurs se répartissent sur plusieurs paliers, la plupart des ordinateurs portables d’entreprise se posent sur le 720p une fois que la logique adaptative de HLS a trouvé le palier confortable, ce qui place la capacité simultanée réaliste d’un seul serveur 10 Gbps à plusieurs milliers de collaborateurs.
Si votre audience dépasse ce seuil, l’étape suivante n’est pas un SaaS. C’est un second serveur interne, ou votre CDN interne existant (la plupart des grandes entreprises ont déjà une infrastructure de cache pour les mises à jour logicielles et les contenus intranet), ou un simple étage de cache nginx devant le serveur de réception. Rien de tout cela ne nécessite un fournisseur, et tout est moins cher qu’une facturation SaaS au spectateur.
Quand l’audience est trop grande pour l’unicast
Le calcul unicast LAN ci-dessus plafonne autour de plusieurs milliers de spectateurs simultanés par serveur. Si un all-hands mondial fait atterrir 50 000 collaborateurs sur le réseau du même bâtiment à la même minute, ou si vous diffusez vers un site de la taille d’un stade rempli d’ordinateurs portables d’entreprise, l’unicast atteint un mur, et empiler les serveurs devient du gaspillage.
La réponse traditionnelle, c’est le multicast : un seul exemplaire de chaque segment circule vers un groupe multicast, chaque spectateur s’y abonne, et le réseau duplique les paquets dans les commutateurs et les routeurs au fur et à mesure. Un seul flux 5 Mbps alimente tout le campus depuis une source unique, sans multiplication de bande passante par spectateur.
En pratique, le multicast sur un réseau d’entreprise relève souvent du “oui, mais” :
- Il ne fonctionne qu’à l’intérieur d’un réseau compatible multicast. La plupart des réseaux d’entreprise ont IGMP et PIM désactivés par défaut pour des raisons de sécurité. Les activer est un projet d’ingénierie réseau, pas un simple paramètre.
- Il ne franchit pas la plupart des connexions VPN. Les télétravailleurs basculent en unicast.
- Il ne franchit pas les liens WAN entre bureaux sans MPLS multicast explicite ou équivalent.
- Il est surtout utile à l’intérieur d’un campus ou d’un bâtiment où la DSI a délibérément construit les arbres multicast.
Si votre réseau le supporte, la façon de l’utiliser avec cette architecture, c’est de laisser le Mac encodeur faire ce qu’il fait (HLS via HTTPS PUT vers le serveur web interne) et d’ajouter un traducteur multicast en aval. Des outils open source comme tsduck et des appliances commerciales fournies par les équipementiers réseau viennent suivre la sortie HLS, construire un flux multicast MPEG-TS, et l’annoncer via SAP ou SDP. Les terminaux qui supportent le multicast (VLC, set-top boxes des salles de réunion, smart TV de la cafétéria) rejoignent le groupe au lieu de tirer du HLS unicast. Ceux qui ne le supportent pas (la plupart des laptops dans un navigateur) continuent d’utiliser le lecteur HLS unicast servi par le même serveur web. Un seul Mac, une seule destination de réception, plus un unique traducteur multicast couvrent les deux types de spectateurs.
Pour la majorité des entreprises, cette section reste théorique : l’unicast absorbe l’all-hands sans difficulté. Pour les rares grands groupes où ce n’est pas théorique, l’architecture s’étend sans toucher à l’encodeur.
Mettre tout ça en place la première fois
La première mise en route prend environ un après-midi à une équipe IT qui n’a jamais fait de streaming interne. L’ordre approximatif :
Choisir le serveur web de destination. N’importe quel serveur web interne en HTTPS convient. Configurer un répertoire du type
/intranet-broadcasts/town-hall-2025-q4/avec HTTPS PUT activé, sans authentification s’il est derrière le pare-feu, ou en authentification basique si vous préférez. nginx avec ledav_modulefait ça en environ dix lignes de configuration.mod_davd’Apache est l’équivalent.Tester le point de terminaison. Depuis n’importe quelle machine interne,
curl -X PUT https://intranet.corp/intranet-broadcasts/test/index.m3u8 --data "test"doit renvoyer un 201. Si c’est le cas, la destination est prête.Configurer My Live TV Channel sur le Mac de l’intervenant. Ajouter une destination HTTP PUT pointant vers le répertoire. Enregistrer. Tester la connexion. Créer un Stream Profile avec l’échelle de débits souhaitée.
Embarquer un lecteur HLS dans la page intranet. Une balise
<video controls>qui pointe vers l’URL de lecture suffit sur Safari. Pour Chrome et Edge, ajoutez hls.js (une balise script, une ligne de JavaScript). Le lecteur complet tient en moins de trente lignes de HTML.Faire une répétition avec l’équipe technique. Diffuser depuis le Mac pendant dix minutes. Faire se connecter quelques spectateurs internes. Surveiller le tableau de bord. Vérifier que les segments arrivent bien sur le serveur de destination, que le lecteur les récupère, et que la latence est acceptable.
Voilà toute la mise en place. Les diffusions suivantes réutilisent la même destination, le même profil, et le même embed du lecteur.
Et le Q&A, les sondages, le reste
L’architecture ci-dessus prend en charge la diffusion, pas la couche interactive. Pour le Q&A, les sondages, et les réactions pendant le town hall, les entreprises ont en général déjà un canal Slack ou Microsoft Teams qui fait parfaitement l’affaire, qui tourne en latence sub-seconde sur le même réseau interne, et qui s’intègre à l’annuaire utilisé par le reste de l’entreprise. Vouloir transformer en plus un SaaS de streaming en outil de chat, c’est exactement ce qui rend ces produits chers. Séparer la diffusion et l’interaction dans les outils que votre entreprise utilise déjà, c’est ce qui rend l’architecture peu coûteuse.
Si vous voulez une chaîne d’information interne 24/7 (“CorpTV”), l’application de playout My TV Channel remplit le temps entre les diffusions en direct avec des contenus programmés (archives d’all-hands, vidéos de formation, actualités internes, messages des managers). Même serveur de destination, même embed du lecteur. Les collaborateurs qui tombent sur la page de la chaîne un mardi après-midi trouvent quelque chose en train de jouer, plutôt qu’un écran “stream offline”.
Ce qui reste à votre charge
Auto-héberger la vidéo interne implique des compromis qu’il vaut mieux assumer.
Enregistrement et rétention. Le serveur de destination conserve indéfiniment chaque diffusion, sauf si vous mettez en place un job de nettoyage. C’est une bonne nouvelle pour les archives, une mauvaise pour le stockage si vous oubliez. La plupart des entreprises veulent une politique de rétention sur les diffusions internes (généralement alignée sur les exigences réglementaires ou légales). À configurer une fois, dans cron, et à oublier ensuite.
Sous-titres et accessibilité. Le sous-titrage en direct n’est pas intégré à l’application encodeur, et ça pose au final moins de problèmes qu’il n’y paraît. Les navigateurs et systèmes d’exploitation modernes génèrent les sous-titres en direct côté client, sur l’appareil, sans intervention serveur : la fonction Live Caption de Chrome marche sur n’importe quelle vidéo lue dans le navigateur, macOS Live Captions fait la même chose à l’échelle du système dans Safari, Edge a son équivalent. Chaque spectateur active ou désactive les sous-titres dans son propre navigateur. S’il vous faut un sous-titrage côté serveur pour des raisons de conformité (les sous-titres doivent faire partie de l’enregistrement, ou vous ne pouvez pas vous reposer sur le navigateur du spectateur), routez l’audio vers un service de sous-titrage (sous-titres intégrés Microsoft, AWS Transcribe, outils internes) et superposez les sous-titres dans le lecteur. La couche HLS ne change ni dans un cas ni dans l’autre.
Authentification. Derrière le pare-feu, “toute personne sur le réseau d’entreprise peut regarder” est souvent acceptable. S’il vous faut des garanties plus fortes (briefings exécutifs, annonces M&A), placez l’URL de lecture derrière votre SSO existant ou les contrôles de posture VPN. De l’authentification web standard, pas spécifique à la vidéo.
Bureaux multi-régions. Si vous avez des bureaux sur plusieurs continents qui rejoignent une même diffusion, il vous faudra soit un serveur de cache régional dans chaque zone, soit une décision assumée d’utiliser le WAN d’entreprise. Les WAN sont en général à débit limité, donc le calcul LAN ci-dessus ne s’applique pas. À planifier en conséquence.
Le verdict honnête
La question du coût est la plus facile à surestimer. Les factures SaaS pour le streaming interne existent, mais elles sont rarement à elles seules le facteur déterminant. Pour la plupart des entreprises qui basculent vers une architecture on-prem, le facteur décisif, c’est que la vidéo interne doit rester interne. La voix du PDG, l’annonce technique, le briefing M&A, le débrief d’incident de sécurité, la formation conformité : aucun de ces contenus n’a besoin de quitter le réseau d’entreprise pour être délivré à l’audience d’entreprise qui s’y trouve déjà. Une fois ce cadre posé, “on envoie une copie via le datacenter d’un fournisseur et on paie l’aller-retour” devient la partie qui appelle une justification, pas l’alternative on-prem.
Les équipes conformité posent la même question dans les industries réglementées : quels tiers ont accès aux enregistrements des réunions internes des collaborateurs ? Les équipes sécurité la posent après chaque divulgation de fuite mentionnant un fournisseur de streaming. Les règles de résidence des données, dans certaines régions, la posent avant même que la diffusion n’ait lieu. Une architecture où les octets ne quittent jamais le réseau supprime la question.
Si vous avez ces préoccupations et que votre équipe IT en a assez de provisionner l’agent eCDN d’un énième fournisseur sur chaque ordinateur portable, la réponse pratique tient désormais en un après-midi de mise en place. Un Mac dans la salle de réunion, un serveur web que vous avez déjà, et une application que vous pouvez essayer gratuitement pendant une semaine. Le schéma d’architecture tient sur un Post-it. Le nombre de fournisseurs qui ont accès à la voix de votre PDG passe de “plusieurs” à “zéro”.
Essayez My Live TV Channel gratuitement pendant 7 jours sur le Mac App Store →