Illustration générée par IA — visuel conceptuel.
Dans un hôtel, le casting est un service client de plus en plus attendu : le voyageur veut retrouver ses contenus sur la TV de sa chambre, sans passer par des logins sur un appareil partagé. Côté exploitation, l’objectif est tout aussi clair : aucun client ne doit pouvoir découvrir (ni caster vers) la TV d’une autre chambre.
Le problème récurrent vient d’un malentendu d’architecture : la “découverte” (device discovery) et la “segmentation” (isolation réseau) ne suivent pas les mêmes règles. En pratique, on segmentera très volontiers avec des VLAN et des SSID, puis on s’étonnera que le casting ne fonctionne plus… ou, à l’inverse, on ouvrira trop large et on créera un risque de cross-room.
Ce guide propose une lecture agnostique des marques : principes mDNS/Bonjour, architectures possibles, et recette (tests) à exiger avant déploiement.
Le vrai sujet : “découverte” ≠ “segmentation”
Dans la plupart des environnements hôteliers, on veut simultanément :
- Segmenter les clients entre eux (confidentialité et sécurité), et isoler les réseaux métiers (PMS, GRMS, CCTV, VoIP, administration) du réseau invité.
- Autoriser localement une interaction très spécifique : le smartphone du client doit trouver et joindre uniquement le receiver de sa chambre (TV, dongle, set-top box, solution intégrée Hospitality TV).
Or la découverte AirPlay et une grande partie des implémentations “Cast” reposent sur des mécanismes de type mDNS/DNS‑SD (Bonjour). Ces annonces sont, par conception, locales au segment réseau : c’est utile à la maison, mais en hôtel cela se heurte immédiatement aux frontières L3 (VLAN) et aux politiques d’isolation Wi‑Fi.
Rappel technique : pourquoi mDNS se “casse” dès qu’on segmente
mDNS/Bonjour : conçu pour le local
mDNS (Multicast DNS) est conçu pour une découverte link‑local. Concrètement, un terminal envoie typiquement ses requêtes mDNS vers 224.0.0.251:5353 (IPv4) et FF02::FB:5353 (IPv6) (RFC 6762).
Conséquence opérationnelle : ce trafic n’est pas destiné à être routé entre sous-réseaux. En pratique, la plage multicast 224.0.0.0/24 (où se trouve 224.0.0.251) correspond à du Local Network Control ; l’IANA indique que les routeurs multicast ne doivent pas forwarder des datagrammes à destination de ce bloc, regardless of its TTL. Donc, dès que vous traversez une frontière L3 (souvent un VLAN), la découverte ne “passe” plus comme à la maison — et le bon réflexe devient de concevoir une passerelle/proxy mDNS (avec filtrage), plutôt que d’espérer “router le multicast”.
AirPlay : plusieurs méthodes de découverte (Bonjour, BTLE, peer-to-peer)
Apple précise qu’un appareil peut découvrir un Apple TV par Bonjour, par advertisement d’adresse IP via Bluetooth Low Energy, ou via une découverte peer-to-peer (AirPlay). Les appareils préfèrent le peer-to-peer, mais peuvent établir la connexion via la méthode jugée la plus “responsive” ou la plus récemment utilisée.
Dans le cas de la découverte Bonjour (mDNS), Apple rappelle aussi le point clé côté réseau : Bonjour s’appuie sur du multicast et, comme le multicast n’est généralement pas routé entre sous-réseaux, ce mode requiert que les équipements soient sur le même sous-réseau IP pour une découverte simple. Sur des réseaux plus larges, Apple indique qu’une Bonjour gateway (ou technologie similaire) peut être utilisée ; et que les réseaux utilisant ce type de mécanisme pour AirPlay doivent annoncer _airplay._tcp et _raop._tcp, en précisant qu’AirPlay requiert une découverte “live” (et pas seulement une publicité DNS “avancée”).
Point de vigilance projet (hôtel) : les modes BTLE / peer‑to‑peer existent et peuvent faciliter certaines situations, mais ils sont à qualifier avec la politique IT/sécurité et l’architecture d’isolation retenue. Dans beaucoup de projets, on cherche au contraire un comportement prévisible et gouverné (découverte “par chambre” et remise à zéro en fin de séjour), ce qui amène souvent à privilégier une approche réseau (Bonjour/mDNS avec filtrage, ou gateway) recettée et documentée.
Chromecast / Cast : traiter la découverte comme un sujet mDNS (avant d’ouvrir des ports)
Sur le terrain, un réflexe utile consiste à séparer :
- Découverte : “je vois le receiver dans la liste”.
- Contrôle : “je sélectionne la TV, je lance la lecture”.
- Média : “le flux audio/vidéo se lance et reste stable”.
Un blocage fréquent est au premier niveau : la découverte ne traverse pas une segmentation L3, ou elle est stoppée par une isolation Wi‑Fi. Côté Cast, on retrouve typiquement une requête mDNS sur un type de service du style _googlecast._tcp.local (voir la documentation Google Cast de dépannage découverte). Avant de multiplier des règles firewall, il faut donc valider le plan de découverte (et sa politique “par chambre”).
Trois architectures possibles (et leurs compromis)
Il n’existe pas une architecture universelle : tout dépend du niveau d’isolation attendu, de la capacité d’exploitation (maintenance), et de l’intégration TV retenue (IPTV, Hospitality TV, dongles, receivers intégrés).
Architecture A — Segment “par chambre” (VLAN / micro‑segmentation)
Principe : chaque chambre dispose de son propre segment IP, sur lequel cohabitent les terminaux du client et le receiver de la chambre.
- Atout : la découverte et le casting deviennent souvent plus simples conceptuellement : on reste “local”.
- Point d’attention : la charge d’exploitation augmente fortement : adressage, DHCP, supervision, troubleshooting, et cohérence de configuration sur un grand parc.
Cette approche est cohérente quand l’objectif d’isolation est très élevé et que le réseau est déjà fortement industrialisé (automatisation, templates, exploitation outillée).
Architecture B — VLAN clients + VLAN TV, avec passerelle mDNS/Bonjour (souvent envisagée)
Principe :
- Les clients restent sur un VLAN/SSID invité (ou un ensemble de VLAN invités).
- Les TVs/receivers restent dans un VLAN dédié (TV/Rooms/AV).
- Une passerelle mDNS (selon constructeurs : “Bonjour gateway”, “mDNS gateway”, “AirGroup”, etc. — exemples non exhaustifs) proxy/cache les annonces et les rend visibles de façon sélective entre segments.
Ce que vous cherchez à obtenir n’est pas “le multicast partout” : c’est une visibilité contrôlée. En hôtellerie, la question n’est donc pas seulement “comment traverser les VLAN”, mais surtout :
- Comment associer un client à sa chambre (ou à une zone) ?
- Comment publier uniquement le receiver pertinent (et pas toutes les TVs de l’étage) ?
À cadrer sans hypothèse de marque : pour AirPlay, Apple mentionne explicitement l’annonce des services _airplay._tcp et _raop._tcp lorsqu’une gateway Bonjour est utilisée. Pour Google Cast, la documentation de dépannage renvoie au service _googlecast._tcp.local côté découverte. Les flux de contrôle/média au-delà de la découverte doivent ensuite être établis sur la base des receivers réellement déployés (TV intégrée, dongle, set‑top box, etc.) et validés en recette.
Cette architecture s’intègre naturellement dans une conception plus large de réseau convergé (Wi‑Fi, IPTV, VoIP, CCTV, GRMS). Voir : Architecture réseau IP d’un hôtel.
Architecture C — Même VLAN, avec “client isolation” (à manier avec prudence)
Principe : on place clients et receivers dans le même VLAN, puis on active une isolation “client-to-client” sur le WLAN.
- Atout : simplifie le routage (tout est “local”).
- Risque : une isolation Wi‑Fi stricte bloque précisément ce que vous voulez autoriser (client → receiver), car le receiver est souvent vu comme “un autre client”. On finit alors par empiler des exceptions (allowlist) et l’ensemble devient difficile à maintenir.
Réserve importante : les fonctions d’isolation (périmètre, exceptions possibles, logique “same‑AP” vs “multi‑AP”, allowlists) varient fortement selon les plateformes Wi‑Fi et leurs versions. Dans un projet hôtelier, ce point doit être considéré comme à vérifier en recette, et non comme une hypothèse.
Cette approche peut fonctionner si vous maîtrisez très précisément les exceptions (et si le receiver n’est pas un client Wi‑Fi “classique” ou si sa politique est gérée nativement par la plateforme de casting/hospitality).
Concevoir une expérience “par chambre” : principes agnostiques
L’objectif, quel que soit le constructeur Wi‑Fi/TV, peut se résumer ainsi :
Un terminal client ne doit découvrir (mDNS) et joindre (contrôle/média) que le receiver de la chambre (ou du groupe de chambres) où il séjourne.
Pour y parvenir, on retrouve généralement trois leviers (souvent combinés) :
Approche “localisation réseau”
On déduit la chambre (ou la zone) à partir d’indices réseau : AP, étage, switchport, micro-segmentation, etc. C’est une méthode robuste quand l’infrastructure est bien documentée et stable (ce qui suppose un DOE réseau propre).
Approche “identité” (rôle / attributs / accès)
On associe l’accès du client à un rôle/identité exploitable par les politiques réseau (par exemple via les mécanismes d’authentification du Wi‑Fi invité). Attention : cela ne signifie pas “rendre le casting dépendant d’une usine à gaz”. Cela signifie définir un attribut exploitable pour filtrer la découverte.
Pour replacer ce sujet dans une stratégie globale de Wi‑Fi invité (parcours client, isolement, portail captif), voir : Wi‑Fi invités : sécurité, portail captif, isolation et expérience client.
Approche “inventaire des receivers” (TV/receivers déclarés et gouvernés)
Dans un hôtel, on ne veut pas “découvrir tout ce qui diffuse”. Il faut une base propre des receivers autorisés, correctement nommés, et une politique qui évite les dérives (TV remplacée, dongle déplacé, receiver réinitialisé, etc.). C’est un sujet d’exploitation, pas seulement de réseau.
Recette (tests) : la checklist qui évite les mauvaises surprises
Avant d’équiper des étages entiers, recetez une zone pilote (ou une chambre témoin) avec une grille de tests. La logique est proche de la méthode “mock-up” que l’on applique déjà au GRMS et aux parcours client en chambre (voir : Chambre témoin hôtel).
| Bloc à tester | Test réalisable | Ce que le test prouve (et ce qu’il ne prouve pas) |
|---|---|---|
| Découverte mDNS | Depuis le smartphone, vérifier que la TV/receiver de la chambre apparaît rapidement et de façon stable (entrées/sorties de veille, redémarrage AP, redémarrage receiver). | Prouve que le plan de découverte est opérationnel. Ne prouve pas que le flux média sera stable en charge. |
| Anti cross-room | Depuis une chambre A : vérifier l’absence de visibilité des receivers des chambres B/C. Répéter depuis chambre B. | Prouve que la politique “par chambre” fonctionne. Ne prouve pas que les exceptions réseau sont minimales (à auditer). |
| Isolation Wi‑Fi | Activer l’isolation client et confirmer précisément ce qui est bloqué/autorisé (client ↔ receiver, client ↔ client, client ↔ gateway). | Prouve le comportement réel (souvent différent des hypothèses). Ne remplace pas la validation d’une politique durable (éviter l’allowlist “infinie”). |
| Roaming | Lancer un cast puis se déplacer dans la chambre, le couloir (selon le cas d’usage) et observer la continuité ou la reprise. | Prouve la tolérance du service aux changements de cellule. Ne prouve pas la performance en simultanéité (à tester séparément). |
| Charge / simultanéité | Organiser un test réaliste : plusieurs casts en parallèle sur une zone pilote, tout en gardant une navigation Internet “normale”. | Prouve la tenue de l’architecture en conditions proches du réel. Ne remplace pas une supervision continue en exploitation. |
| Modes dégradés | Simuler : perte d’un lien d’étage, redémarrage contrôleur Wi‑Fi, indisponibilité d’une passerelle mDNS (si utilisée), redémarrage de TV/receiver. | Prouve ce que vivra l’exploitation lors d’un incident. Ne remplace pas un runbook clair (qui fait quoi, dans quel ordre). |
Points d’attention : TV, casting et exploitation hôtelière
Ne pas confondre “TV connectée” et “Hospitality TV”
La capacité de remise à zéro (fin de séjour), le verrouillage des réglages, la gestion centralisée et l’exploitation quotidienne ne dépendent pas uniquement du réseau. Le choix de la TV (et de l’écosystème) doit être pensé avec la stratégie de casting et la confidentialité. Voir : Hospitality TV : différence avec une Smart TV classique.
IPTV, coaxial et casting : ne mélangez pas les sujets
Un casting “par chambre” ne nécessite pas forcément une migration IPTV complète : dans certains contextes, des établissements conservent le coaxial pour les chaînes linéaires tout en ajoutant un plan IP pour le casting. Le point dur reste souvent : réseau IP, segmentation, Wi‑Fi et politique mDNS. Pour l’arbitrage IPTV/coax : IPTV ou télédistribution coaxiale : quelle architecture pour un hôtel.
Le réseau invité doit rester un réseau “invité”, même si vous y autorisez du casting
Autoriser un casting contrôlé ne justifie pas d’ouvrir des flux inutiles vers des réseaux métiers ou techniques. La séparation VLAN/pare-feu et une gouvernance claire des flux restent indispensables (voir : Wi‑Fi invités et VLAN).
Conclusion : réussir le casting en hôtel, c’est “designer” la découverte
Pour permettre AirPlay/Chromecast en hôtel sans casser l’isolation des chambres, le point clé n’est pas de “choisir un VLAN”. Le point clé est de traiter la découverte mDNS/Bonjour comme un système : périmètre, politiques, association client ↔ chambre, et recette exploitable.
Vous envisagez une architecture de casting par chambre, ou vous corrigez un site où « le casting marche une fois sur deux » ? Nous pouvons vous aider à cadrer une matrice d’architecture (réseau/Wi‑Fi/TV) et une recette adaptée à votre établissement, en cohérence avec votre réseau IP hôtelier.
Références techniques (pour approfondir)
- RFC 6762 — Multicast DNS (mDNS)
- IANA — IPv4 Multicast Address Space (224.0.0.0/24)
- Apple — Deployment guide (AirPlay discovery, Bonjour gateway)
- Chromium Open Screen — Cast Protocol Flow (document d’overview/implémentation ; discovery via mDNS)
- Google Cast — Discovery troubleshooting (service record _googlecast._tcp.local)
