Category "Réseaux et Wi-Fi"

29Jan

Télévision et vidéo sur réseau : quels tests réaliser avant la mise en service ?

by Domocasa
Guides techniques Réseaux et Wi-Fi TV et Affichage digital

Illustration générée par IA — visuel conceptuel.

Pourquoi recetter le multicast (et pas seulement “vérifier que l’image apparaît”)

En hôtellerie, l’IPTV (set-top box, middleware, Hospitality TV IP) et l’AV-over-IP (encodeurs/décodeurs, distribution vidéo des salles de réunion, affichage, etc.) peuvent s’appuyer sur des flux multicast selon l’architecture retenue. Quand le multicast est en cause, les symptômes possibles incluent :

  • freeze / image qui gèle, macro-blocs, son qui décroche ;
  • zapping lent ou instable ;
  • flooding multicast (le multicast “inonde” un VLAN et dégrade le réseau, parfois au-delà du service TV/AV).

Les causes possibles se situent notamment dans la cohérence entre VLAN, IGMP snooping, présence d’un querier sur le VLAN, et (si nécessaire) routage multicast dès qu’on traverse des sous-réseaux. L’enjeu d’une recette n’est pas de “deviner”, mais de tester et prouver ces points (tables, captures, chemins).

Rappels utiles (strict minimum) : ce que la recette doit permettre de vérifier

IGMP : le contrôle (abonnement) n’est pas le flux (vidéo)

IGMP sert aux équipements récepteurs (TV IP, STB, décodeur AV, PC) à exprimer leur intérêt pour un groupe multicast. Les flux vidéo/audio (souvent en UDP) circulent ensuite sur le réseau. En recette, l’objectif est de valider les deux plans :

  • le control-plane : queries, joins, leaves (IGMP) ;
  • le data-plane : continuité du trafic UDP multicast, absence de pertes, absence de duplication inutile.

Note de cadrage : cet article traite d’IGMP (IPv4). En IPv6, l’équivalent côté abonnements multicast est MLD (les principes de recette restent proches : contrôle des abonnements + acheminement du flux).

IGMP snooping (L2) : éviter que le multicast se comporte comme du broadcast

Sur un réseau Ethernet, un switch qui ne “comprend” pas le multicast peut traiter certains flux multicast comme un trafic à répliquer largement dans un VLAN. Le snooping consiste à “observer” IGMP afin de limiter l’envoi des trames multicast aux seuls ports réellement abonnés.

Point important : la RFC 4541 est un document de type considerations / recommendations (informational). Elle aide à cadrer les objectifs et les risques (flooding, états), mais ne remplace pas la documentation de votre plateforme (switches, WLAN, routeurs).

Le querier : un point à vérifier (preuve par capture + identité)

Pour maintenir les états d’appartenance dans le temps, IGMP s’appuie sur une mécanique de queries et de réponses. En environnement IGMP snooping, la recette doit donc vérifier, sur chaque VLAN multicast, que l’on observe des IGMP General Queries (et identifier clairement qui les émet : routeur multicast sur ce VLAN, ou fonction “querier” de la plateforme selon l’architecture).

En pratique, l’approche la plus robuste est de :

  • capturer au bon endroit (SPAN ou capture au plus près du VLAN) ;
  • observer des General Queries et relever l’émetteur ;
  • documenter ce rôle par VLAN (qui est querier, où, et comment il est configuré).

Si les General Queries ne sont pas observables, ne concluez pas à une “cause” sur la seule intuition : considérez cela comme une hypothèse prioritaire à traiter et cherchez la preuve (capture IGMP + vérification de configuration).

Adressage multicast : identifier le modèle réellement utilisé (239/8 “administratif” vs SSM en 232/8)

La plage 239.0.0.0/8 est définie comme administratively scoped (usage interne, périmètre d’administration). Le bloc 232.0.0.0/8 est réservé aux destinations SSM (Source-Specific Multicast) et implique typiquement l’usage d’IGMPv3 côté abonnements (filtrage de sources). Le point clé en recette n’est pas de “choisir un modèle”, mais de documenter celui qui est réellement utilisé (groupes, VLAN, et sources si SSM) et de vérifier la compatibilité de bout en bout.

Avant la recette : ce qu’il faut exiger (sinon vos tests seront “à l’aveugle”)

Avant d’allumer une TV ou de lancer une vidéo, demandez une matrice claire (IPTV et/ou AV-over-IP) :

  • Sources : IP source, ports UDP, emplacement (headend, encodeur, serveur), ports/switchs ;
  • Groupes multicast : IP groupe, VLAN, et (si applicable) ASM vs SSM ;
  • Chemin réseau : liste des switches traversés, trunks, uplinks, points de routage ;
  • Version IGMP attendue côté terminaux (v2 ou v3) ;
  • Dépendances d’exploitation : qui administre quoi (IT, intégrateur AV, prestataire IPTV), et comment on revient en arrière en cas de changement.

Objectif : transformer cette matrice en protocole de recette avec des critères “vérifiables” (preuves, captures, tables IGMP, comportement par VLAN).

Checklist de recette IGMP/multicast (par VLAN multicast)

Travaillez VLAN par VLAN. Un défaut “sur un VLAN” peut avoir un impact très large si des trunks et des uplinks transportent plusieurs services.

Étape 0 — Hygiène d’architecture (avant d’entrer dans IGMP)

  • Point de conception (à documenter) : séparer le VLAN IPTV/AV (réseau média) des autres zones (ex. invités) et expliciter où le multicast est autorisé (point de recette : vérification VLAN + règles réseau).
  • Trunks cohérents : vérifier qu’aucun trunk ne “perd” le VLAN en chemin, et qu’aucun port d’accès n’est dans le mauvais VLAN. Un défaut de VLAN/trunk peut créer des écarts de fonctionnement entre prises ; à vérifier en recette sur plusieurs points représentatifs (par exemple deux prises proches + une prise éloignée).
  • Wi‑Fi et bridges : si le service traverse une portion Wi‑Fi (ou un pont L2/WLAN), recetez explicitement le traitement du multicast côté WLAN (ex. mécanismes de conversion multicast→unicast, snooping IGMP/MLD, limitations de débit multicast, etc.). Le comportement dépend fortement des contrôleurs/AP et de leurs réglages : ne le présumez pas.

Étape 1 — Tests L2 : IGMP snooping (sur tout le chemin)

  • Test L2-1 : snooping activé partout
    Vérifier que tous les switches traversés par le VLAN appliquent le snooping. Un switch sans snooping (ou mal configuré) sur le chemin peut entraîner du flooding ou des comportements instables ; en recette, vérifiez la cohérence sur tout le chemin.
  • Test L2-2 : table de groupes cohérente
    Sur un switch d’accès, contrôler que les groupes multicast apparaissent avec une liste de ports “abonnés” plausible (ports des STB/TV/décodeurs), et pas une liste de ports quasi complète.
  • Test L2-3 : test négatif anti-flood
    Sur un port d’accès du VLAN sans récepteur, vérifier qu’on ne reçoit pas de flux multicast “TV/AV” en continu. Si vous en recevez, considérez cela comme un signal fort de flooding (ou d’exception volontaire à documenter).
  • Test L2-4 : sortie de groupe (leave) et “fast leave” si pertinent
    Certains constructeurs proposent des options de fast leave / immediate leave pour accélérer la sortie d’un port d’un groupe multicast et réduire les délais de mise à jour. À cadrer comme une option de projet (et pas une règle universelle) :

    • valider le comportement sur votre plateforme (switches + terminaux),
    • et vérifier la topologie de port : certaines implémentations précisent de ne pas activer un “immediate leave” si plusieurs récepteurs peuvent exister derrière un même port (mini-switch, TV + STB, etc.).

Étape 2 — Tests querier : présence, identité et stabilité

  • Test Q-1 : existence de General Queries sur le VLAN
    Faire une capture (SPAN ou capture au plus près) et vérifier qu’on observe bien des IGMP General Queries périodiques.
  • Test Q-2 : “qui est querier” (un rôle identifié)
    Pour chaque VLAN multicast, l’objectif est de pouvoir nommer l’équipement qui joue ce rôle (cœur L3, switch avec fonction querier, etc.) et de l’indiquer dans la documentation d’exploitation.
  • Test Q-3 : stabilité lors d’un événement réaliste
    Simuler (de manière contrôlée) une coupure d’uplink, un redémarrage d’un switch d’accès, ou une mise hors service d’un équipement non critique, puis vérifier que :

    • les flux ne partent pas en flooding,
    • les abonnements reviennent correctement,
    • le querier ne “disparaît” pas ou ne change pas de manière incohérente.

Étape 3 — Tests L3 : seulement si vous traversez des sous-réseaux

Si vos sources et vos récepteurs ne sont pas dans le même domaine L2 (plusieurs VLAN, plusieurs étages, plusieurs bâtiments), il peut être nécessaire de mettre en place du routage multicast (selon l’architecture). Dans ce cas, la recette doit explicitement valider :

  • join dans le VLAN récepteur (IGMP observable) ;
  • présence du flux dans le VLAN récepteur (UDP multicast observable) ;
  • états multicast côté cœur L3 (tables/états de routage multicast selon la plateforme) ;
  • cohérence SSM/IGMPv3 si vous êtes en SSM : les récepteurs doivent joindre avec filtrage de source, et l’infrastructure doit supporter ce modèle sur tout le chemin.

Recommandation de projet : si vous n’avez pas besoin d’inter-VLAN pour le multicast, n’ajoutez pas ce niveau de complexité “par principe”. Si, au contraire, l’architecture impose du L3, documentez explicitement le périmètre, les équipements concernés et les preuves attendues en recette.

Checklist orientée symptômes (diagnostic rapide)

Symptôme : flooding multicast (réseau “qui hurle”)

Signes possibles : uplinks qui montent anormalement, ports non abonnés qui reçoivent les flux, dégradation simultanée d’autres services (Wi‑Fi, VoIP, applicatifs).

Hypothèses prioritaires :

  • snooping absent/désactivé sur un switch du chemin ;
  • table IGMP incohérente (ports “trop nombreux”) ;
  • mauvaise segmentation : le multicast “leak” vers un autre VLAN/zone.

Tests : test négatif anti-flood (port sans abonné), vérification des tables de groupes, vérification que le VLAN est bien contrôlé sur tous les trunks.

Symptôme : freeze, macro-blocs, son qui décroche

Hypothèses prioritaires :

  • pertes de paquets ou congestion sur un segment (uplink, switch d’étage, lien inter-bâtiments) ;
  • flooding partiel qui surcharge certains liens (le multicast arrive “partout”, donc il consomme la capacité) ;
  • mécanique d’abonnement non stable (control-plane IGMP à investiguer : queries/joins/leaves observables et cohérents).

Tests : capture data-plane (UDP multicast) au niveau du récepteur, compteurs d’erreurs et de drops sur les interfaces, et capture IGMP pour vérifier que joins/queries/leaves sont cohérents dans le temps.

Symptôme : zapping lent

Hypothèses prioritaires :

  • mécanismes de leave/join peu efficaces (version IGMP, comportement de l’accès, paramètres/timers selon plateformes) ;
  • problème “à la sortie” : l’ancien flux continue à être servi trop longtemps, ou la table se met à jour lentement ;
  • option de “fast leave” non adaptée à la topologie (à valider précisément selon prises/ports et équipements réels).

Test recette zapping (reproductible) : définir un scénario de zapping identique (mêmes chaînes / mêmes flux), sur plusieurs prises représentatives (chambre, suite, étage éloigné, salle de réunion), puis corréler :

  • timestamp du join/leaves IGMP (capture),
  • arrivée effective du flux UDP multicast côté récepteur,
  • stabilisation audio/vidéo perçue (validation utilisateur).

Méthode de diagnostic “preuve-based” : capturer au bon endroit, au bon moment

Où capturer (ordre conseillé)

  1. Au plus près du récepteur (prise chambre, baie d’étage, port d’accès) : c’est là que l’on observe le symptôme réel.
  2. Sur le switch d’accès via port mirror / SPAN : utile pour voir IGMP et le flux sur le même point.
  3. Au cœur / distribution (si routage multicast ou si vous suspectez un uplink) : utile pour isoler “c’est avant / c’est après”.

Quoi capturer

  • IGMP (control-plane) : queries + joins/leaves, pour valider la mécanique de souscription.
  • UDP multicast (data-plane) : continuité, pertes apparentes, arrivée sur les ports attendus uniquement.

Astuce d’exploitation : préparez une “fiche d’intervention” qui impose la même structure à chaque diagnostic (date/heure, VLAN, groupe multicast, port switch, capture IGMP, capture UDP, hypothèse, action, résultat). Sans cela, les équipes rejouent les mêmes investigations à chaque incident.

Pièges fréquents (à transformer en points de recette)

  • Snooping activé “presque partout” : un switch oublié peut suffire à flooder une zone.
  • Querier non documenté (ou non observable en capture) : ne partez pas d’une hypothèse. Identifiez l’équipement querier par VLAN et vérifiez la présence de General Queries dans le temps.
  • Querier configuré mais non opérationnel : selon les plateformes, certaines conditions (ex. IP d’interface/SVI, état L3) peuvent empêcher l’émission réelle des queries.
  • Version IGMP non cohérente entre terminaux et infrastructure : le “ça marche en labo” ne garantit pas “ça marche à l’hôtel”.
  • SSM/IGMPv3 supposé mais non vérifié : si vous utilisez 232/8, validez le filtrage de sources et le support bout en bout.

Livrables de recette à exiger (pour éviter les incidents répétitifs)

  • PV de recette par VLAN multicast : tests passés, preuves (captures, tables), réserves éventuelles.
  • Exports / sauvegardes des configurations réseau impactant IGMP (snooping, querier, VLAN/trunks, routage si concerné) selon la gouvernance IT.
  • Schéma logique : VLAN, rôle du querier, rôle du cœur L3, zones où le multicast est autorisé.
  • Procédure d’exploitation : quoi vérifier en premier quand un étage “freeze”, et comment escalader (IT / IPTV / AV) sans perdre de temps.

Références (RFC & documentation)

Pour aller plus loin (lecture utile Domocasa)

Les liens ci-dessous sont du maillage interne Domocasa (approfondissements éditoriaux). Ils ne remplacent pas les références RFC / constructeurs ci-dessus.

Si vous préparez une ouverture, une rénovation ou une reprise d’exploitation, l’enjeu n’est pas seulement de “corriger un bug IGMP” : c’est de rendre la recette reproductible et le diagnostic traçable, pour éviter que les gels et le zapping lent reviennent à chaque changement réseau.

22Jan

Vidéophone en immeuble : organiser plusieurs entrées et assurer la continuité du service

by Domocasa
Réseaux et Wi-Fi Sûreté et Sécurité

Illustration générée par IA — visuel conceptuel.

Une interphonie/vidéophonie IP collective (résidence, immeuble, multi-bâtiments) n’est pas une simple transposition d’un vidéophone IP “villa”. À l’échelle d’un collectif — au Maroc comme ailleurs — l’enjeu devient rapidement un sujet réseau + exploitation : annuaire des occupants, multiples entrées, continuité de service, segmentation (VLAN), PoE dimensionné, procédures d’arrivée/départ des résidents, et livrables DOE (dossier des ouvrages exécutés).

Objectif de ce guide : vous aider à cadrer une architecture (sans imposer une marque) et à lister les livrables attendus pour qu’une résidence reste exploitable sur la durée. Pour le contexte “vidéophone IP” (plutôt maison), vous pouvez aussi lire : Vidéophone IP : gérer ses visiteurs et ses accès à distance. Pour replacer l’interphonie dans un schéma plus large d’immeuble (réseau, accès, CCTV, etc.), voir : Courant faible dans un immeuble : quels systèmes prévoir dès la conception ?.

Décider le périmètre fonctionnel avant de parler de matériel

Cartographier les points d’entrée (multi-entrées)

Commencez par un recensement aussi complet que possible des “accès” connus au projet, car c’est lui qui détermine la topologie (réseau, PoE, secours, exploitation) :

  • Entrées piétons : portail, hall principal, halls par bâtiment, entrées secondaires, accès PMR.
  • Accès véhicules : barrière, rideau métallique, portail parking, rampe.
  • Accès internes : portes techniques, locaux communs, zones réservées (salle de sport, rooftop, etc.).
  • Poste gardien / conciergerie (si présent) : rôle dans les appels et l’ouverture.

Chaque entrée n’est pas seulement une platine. En conception, vous devez relier : platine (audio/vidéo) → commande d’ouverture (gâche/ventouse/serrure/automatisme) → alimentation → réseau → terminaux d’appel (appartements, gardien, application).

Définir l’expérience “résident” et les terminaux

Dans un collectif, le choix des terminaux est aussi un choix d’exploitation. On rencontre typiquement :

  • Moniteurs intérieurs IP (écran) et/ou postes audio (selon standing et contraintes de câblage).
  • Application mobile (confort, mais dépendances à cadrer : comptes, Internet, service externe selon solution).
  • Poste de gardien/PC conciergerie : réponse de 1er niveau, filtrage des appels, ouverture contrôlée.

Définissez ensuite les règles d’appel : appel direct par appartement, recherche par annuaire, renvoi vers gardien, escalade si non-réponse, plage horaires “jour/nuit”, etc. Une architecture propre est celle qui rend ces règles explicites et testables, plutôt que “magiques”.

Clarifier la frontière interphonie vs contrôle d’accès

En immeuble, l’interphonie touche nécessairement au contrôle d’accès : badges, codes, horaires, listes blanches, journalisation des événements… Deux approches sont possibles :

  • Interphonie qui embarque une partie des fonctions d’accès (badges/codes/horaires) : cohérent si l’exploitation reste simple et si les exports/sauvegardes sont prévus.
  • Contrôle d’accès dédié (plus structurant) + interphonie “visiteurs” : souvent préférable dès que la résidence a beaucoup d’accès internes/techniques, des profils multiples (résidents, prestataires, syndic), ou une gouvernance plus exigeante.

Il n’y a pas de “bonne réponse universelle” : l’important est de décider qui fait quoi, où réside la logique d’autorisation, et comment vous maintenez/transposez les données (annuaire, badges, droits) dans la durée.

Comprendre la chaîne IP : signalisation, médias, ouverture (et ce que ça implique)

Beaucoup de solutions d’interphonie IP s’appuient sur des briques réseau classiques. Selon les architectures, la partie “sessions d’appel” peut utiliser SIP lorsqu’une platine ou un poste doit s’enregistrer auprès d’un serveur SIP / IPBX (ou dialoguer avec un environnement VoIP). Pour les médias (audio/vidéo) et le streaming, on rencontre ensuite, selon les fabricants, des mécanismes et protocoles dédiés (par exemple RTP/RTSP, ou des flux propriétaires), parfois complétés par des API (HTTP/HTTPS) pour certaines fonctions (administration, instantanés, intégrations). L’existence de SIP ne garantit pas à elle seule l’interopérabilité “multi-marques” (cela dépend de l’implémentation), mais cela rappelle un point clé : vous traitez un système temps réel et un système d’accès — donc à concevoir comme une infrastructure critique, pas comme un gadget connecté.

Conséquence projet : segmenter, durcir, documenter, et tester les modes dégradés. Dans un collectif, une panne devient immédiatement un incident “multi-résidents”.

Topologies “immeuble” : centralisée ou distribuée ?

Architecture centralisée (cœur unique)

Une plateforme (serveur/contrôleur) centralise annuaire, règles d’appel, droits et supervision, avec des platines aux entrées.

  • Avantages : administration centralisée, annuaire unique, reporting unifié.
  • Point d’attention : point unique de panne si l’architecture ne prévoit pas d’autonomie locale des entrées ou de mécanisme de redondance.

Architecture distribuée (par bâtiment / par entrée)

Des contrôleurs locaux gardent les règles critiques au plus près des entrées (badges/portes), avec une supervision ou une administration centrale.

  • Avantages : résilience locale (une panne n’affecte pas toute la résidence), segmentation naturelle par bâtiment.
  • Point d’attention : complexité (synchronisation d’annuaire, sauvegardes, versions), et besoin d’un DOE plus rigoureux.

Recommandation de conception : plus le site est multi-bâtiments et multi-entrées, plus une logique distribuée (au moins par zones) devient pertinente — à condition de cadrer le DOE, la recette et l’exploitation.

Réseau : VLAN interphonie, routage maîtrisé et plan d’adressage exploitable

Créer un VLAN “interphonie” (et filtrer)

En immeuble, partez du principe que l’interphonie doit vivre dans un VLAN dédié, avec des règles de filtrage inter-VLAN définies au projet. Sur Ethernet, un VLAN se matérialise généralement par l’affectation de ports (ports d’accès non taggés pour les équipements finaux) et, lorsque plusieurs VLAN doivent traverser un même lien (entre switchs, vers un pare-feu, vers un cœur), par du tagging IEEE 802.1Q sur des liaisons trunk. Pour le “pourquoi” et la méthode, voir notre guide : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?.

Selon l’architecture, vous pouvez scinder :

  • un VLAN interphonie/terminaux (platines, moniteurs, postes concierge),
  • un VLAN management (interfaces d’administration) si cela améliore la sécurité et l’exploitation.

Éviter d’étendre du L2 “partout” en multi-bâtiments

Une erreur fréquente consiste à “tirer un grand réseau L2” sur tous les bâtiments sans raison. En multi-bâtiments, on vise souvent :

  • un L2 local (switchs PoE d’accès) au plus près des entrées,
  • une agrégation vers un cœur L3 (routage inter-VLAN, contrôle des flux),
  • des règles explicites : qui parle à qui (terminaux ↔ serveur, conciergerie ↔ équipements, administration ↔ management), et rien de plus.

Ce choix simplifie le diagnostic, limite les “effets de bord” et aide à contenir un incident à une zone.

Adressage et nommage : indispensable en collectif

En résidence, l’adressage n’est pas un détail IT : il conditionne le SAV et les extensions. Exigez au minimum :

  • un plan d’adressage (par bâtiment/entrée, cohérent et documenté),
  • des IP stables (IP fixes ou réservations DHCP selon la gouvernance retenue),
  • une nomenclature lisible (ex. BÂT-A / HALL-01 / PLATINE-01),
  • un tableau “port switch ↔ équipement ↔ emplacement”.

Pour cadrer la remise documentaire réseau (schémas + configurations), voir : Documentation réseau : quels schémas et sauvegardes remettre au client ?.

PoE interphonie : dimensionner la puissance (et prévoir le secours)

Le PoE (Power over Ethernet) est souvent la solution la plus rationnelle en immeuble : moins d’alimentations locales, maintenance centralisée, et possibilité d’UPS sur les switchs pour tenir des pannes courtes. Mais en collectif, “avoir du PoE” ne suffit pas : il faut dimensionner le budget puissance et le documenter.

Point de cadrage utile : les termes PoE / PoE+ / PoE++ sont souvent utilisés comme raccourcis commerciaux. Pour éviter les contresens, ramenez-les systématiquement aux familles IEEE 802.3af / 802.3at / 802.3bt (et, pour 802.3bt, au type réellement supporté). Et distinguez bien la puissance au port du switch (côté source) de la puissance réellement disponible au terminal (côté appareil) : le budget du switch ne se lit pas “uniquement” sur l’étiquette des ports.

Ce qu’il faut vérifier côté équipements

  • Type de PoE accepté (PoE/PoE+/PoE++ selon terminaux).
  • Consommation maximale annoncée (à utiliser pour le budget, pas la consommation “typique”).
  • Fonctions qui augmentent la puissance (ex. écran, IR, chauffage, etc. selon matériels).

Méthode de dimensionnement (simple et défendable)

  1. Listez tous les équipements PoE (platines, moniteurs, éventuelles caméras associées, points d’appel, etc.).
  2. Prenez la consommation max de chaque équipement (hypothèse “pire cas”).
  3. Répartissez par switch (local technique / hall / bâtiment).
  4. Vérifiez : puissance max par port et budget PoE total du switch.
  5. Gardez une réserve (évolution, marge d’exploitation).

Pour la méthode détaillée (et les pièges “ports PoE+” vs budget total), voir : PoE, PoE+ et PoE++ : comment dimensionner la puissance d’un switch ?.

UPS : clarifier ce qui doit rester actif en coupure

La question utile n’est pas “mettre un onduleur”, mais : quels services doivent survivre à une coupure courte ? Exemples à trancher au projet :

  • platines des entrées principales,
  • poste de gardien/conciergerie,
  • éléments réseau (switch PoE du hall / distribution).

Attention : l’UPS réseau ne garantit pas à lui seul l’ouverture des portes. Les organes d’ouverture (gâche, ventouse, automatisme) ont leur propre logique d’alimentation, à traiter avec le lot serrurerie/électricité et selon la stratégie sûreté retenue (comportement en perte d’alimentation).

Résilience : définir des modes dégradés réalistes… et les tester

En immeuble, “ça marche la plupart du temps” est insuffisant. Les modes dégradés doivent être écrits (cahier des charges) puis recettés sur site, parce que le comportement exact dépend fortement de la solution choisie (autonomie locale, dépendance à un serveur, dépendance Internet, etc.).

Précaution exploitation : sur une résidence en exploitation, les tests de panne (Internet, switch PoE, cœur réseau, serveur) ne se font pas “au fil de l’eau”. Prévoyez une fenêtre d’intervention, une communication adaptée (gardien/syndic/résidents selon cas), et validez à l’avance les conséquences acceptables sur les accès. L’objectif est de tester, pas de créer un incident réel.

Grille de tests de recette (exemples opérationnels)

Incident simulé Test réalisable sur site Limite / point de vigilance
Perte Internet Couper la liaison WAN et vérifier appels internes, poste gardien, ouverture locale L’appel smartphone peut tomber (selon architecture). À documenter clairement.
Panne switch PoE d’un hall Couper un switch PoE (ou désactiver PoE) et mesurer l’impact par entrée Vérifier l’alarme/diagnostic : l’exploitation doit “voir” la panne.
Panne cœur réseau / routage Isoler le cœur L3 et vérifier ce qui continue localement Selon design, certaines entrées peuvent rester autonomes, d’autres non.
Panne plateforme/serveur interphonie Arrêt contrôlé du serveur et test des parcours critiques Décider si une redondance est nécessaire (selon criticité).
Coupure secteur Couper l’alimentation du tableau local (zone test) et contrôler reprise Tester aussi le redémarrage : certains systèmes échouent au “retour”.

Si ces tests ne sont pas acceptables en conditions réelles (résidence déjà habitée), ils peuvent être réalisés sur un périmètre pilote (un hall) ou sous forme de fenêtre d’intervention planifiée, mais ils ne doivent pas être “oubliés” : c’est la recette qui révèle les dépendances cachées.

Séparation réseau et durcissement : VLAN, filtrage, et 802.1X si pertinent

L’interphonie est un système d’accès : elle mérite donc une approche “sécurité par conception” :

  • Segmentation (VLAN) + filtrage inter-VLAN (pare-feu / ACL) selon les flux réellement nécessaires.
  • Interfaces d’administration sur un segment dédié (quand pertinent), accès restreint, comptes nominatifs si possible.
  • Éviter les expositions directes (redirections de ports “pour dépanner”) : préférer une méthode d’accès distant maîtrisée (VPN / accès temporaire), selon gouvernance du projet.

802.1X : excellent, mais seulement si l’exploitation peut le maintenir

Le contrôle d’accès réseau par port (802.1X) peut renforcer la protection contre un branchement “sauvage” dans un hall. Mais c’est une exigence d’exploitation : gestion des identités, certificats (selon design), procédures de remplacement matériel. Si la résidence ne dispose pas d’une gouvernance IT adaptée, un durcissement plus simple (ports verrouillés, VLAN stricts, filtrage, management isolé) peut être plus robuste dans la durée.

Gestion des occupants : annuaire, arrivées/départs, et “qui administre quoi”

Le collectif exige un process, pas seulement un système. À cadrer dès la conception :

  • Qui crée/supprime un résident (gardien, syndic, prestataire) ?
  • Quel délai de désactivation (badges, codes, comptes applicatifs) après départ ?
  • Quelle traçabilité minimale (journalisation des actions d’administration) ?
  • Comment récupérer l’annuaire et les paramètres en cas de changement de prestataire (export, sauvegarde, formats) ?

Sans ces réponses, vous obtenez des systèmes “fonctionnels” à la livraison… mais fragiles dès que la résidence change de syndic, d’exploitant, ou que les premiers lots sont revendus.

DOE interphonie IP en immeuble : la liste de livrables à exiger

La qualité d’un projet collectif se voit aussi dans sa documentation. Le DOE doit permettre une maintenance, un dépannage et une reprise par un autre intervenant si nécessaire. Vous pouvez organiser les livrables en trois ensembles.

DOE réseau (infrastructure)

  • Schéma physique : baies, switchs, uplinks, liaisons inter-bâtiments, repérage réel.
  • Schéma logique : VLAN, sous-réseaux, routage inter-VLAN, filtrage (règles).
  • Table de brassage (ports ↔ prises ↔ équipements) en format éditable.
  • Sauvegardes de configuration réseau (switchs/pare-feu/contrôleur Wi‑Fi si concerné) + versions.

Référence Domocasa : Documentation réseau : quels schémas et sauvegardes remettre au client ?.

DOE interphonie / accès

  • Inventaire : référence, MAC, emplacement, version firmware (si accessible).
  • Paramétrage exporté : annuaire (structure + export), règles d’appel, droits et profils.
  • Plan des entrées : platine ↔ porte ↔ type d’organe de verrouillage ↔ alimentation ↔ comportement en panne.

PV de recette (orienté exploitation)

  • Parcours d’appel : appel, non-réponse, renvoi, ouverture.
  • Tests “modes dégradés” (perte Internet, panne switch PoE, panne serveur) avec résultats.
  • Contrôle de reprise après incident (redémarrage, resynchronisation).

Checklist de conception (à utiliser en réunion BET/architecte/intégrateur)

  1. Plan des accès : combien d’entrées, où, et avec quel niveau de criticité.
  2. Conciergerie : rôle dans les appels, l’ouverture, l’administration.
  3. Terminaux : moniteurs, app mobile, postes, et règles de renvoi (jour/nuit).
  4. Annuaire : confidentialité, recherche, process arrivées/départs.
  5. Réseau : VLAN interphonie, plan IP, filtrage inter-VLAN, management.
  6. PoE : budget par switch, réserve, UPS et périmètre de secours.
  7. Modes dégradés : scénarios écrits + tests de recette planifiés.
  8. DOE : livrables réseau + interphonie + PV de recette.

Aller plus loin (lectures Domocasa utiles)

Si vous préparez un projet précis (multi-bâtiments, nombre d’entrées, présence ou non de gardien, stratégie app mobile, niveau de résilience attendu), l’étape suivante consiste à formaliser une architecture cible et une grille de recette avant consultation des entreprises — afin d’obtenir des offres comparables et une installation maintenable.

Découvrir Domocasa et échanger sur l’architecture la plus cohérente pour votre résidence.

15Jan

Hôtel : partager ses contenus sur la TV sans accéder aux autres chambres

by Domocasa
Hôtellerie Réseaux et Wi-Fi TV et Affichage digital

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)

12Jan

Wi-Fi 6E et 7 : éviter que le câblage et l’alimentation limitent les bornes

by Domocasa
Guides techniques Réseaux et Wi-Fi

Illustration générée par IA — visuel conceptuel.

Pourquoi des bornes Wi‑Fi 6E/7 finissent « bridées » en production

Dans les projets tertiaires (bureaux, hôtellerie, retail), le Wi‑Fi dépend directement de l’infrastructure filaire qui alimente les points d’accès. Une borne peut afficher un excellent niveau de signal et rester pourtant limitée, tout simplement parce que le LAN ou le PoE n’est pas cohérent avec ses besoins.

On rencontre typiquement trois scénarios :

  • Uplink Ethernet trop lent : une borne moderne peut dépasser ce qu’un lien 1 GbE peut absorber. Résultat : vous atteignez un plafond structurel, même si la radio est excellente.
  • PoE insuffisant : l’AP s’allume… mais se met en mode restreint (fonctions désactivées, radios limitées, port(s) Ethernet bridés, USB inactif selon modèle). « Ça marche » et pourtant vous n’avez pas le niveau de service attendu.
  • Câblage / connectique / recette incomplets : un lien peut négocier à la baisse (ou accumuler des erreurs) à cause d’un canal cuivre mal exécuté, d’un patch non conforme, d’un mauvais cheminement ou d’un test de recette trop superficiel.

Ce guide est volontairement transversal : il fait le pont entre le dimensionnement PoE, la conception Wi‑Fi et les décisions de câblage, afin d’éviter les erreurs de coordination entre lots. Pour aller plus loin sur les fondamentaux, vous pouvez aussi lire PoE, PoE+ et PoE++ : comment dimensionner la puissance d’un switch ? et Wi‑Fi 7 en entreprise et hôtellerie : quand devient-il réellement utile ?.

Les trois goulots à traiter ensemble (LAN + PoE + câblage)

Goulot n°1 : 1GbE vs 2.5GbE/5GbE/10GbE — choisir l’uplink AP et le switch multigig

Le Wi‑Fi ne doit pas être dimensionné à partir d’un débit marketing. La question opérationnelle est : quel trafic la borne doit-elle réellement transporter dans vos zones denses (réunion, lobby, restaurant, open space), et à quel moment ?

Un point d’accès récent en environnement dense peut générer un trafic agrégé qui rend un lien 1 GbE trop contraignant. Dans ce cas, vous pouvez avoir une radio performante… et une borne plafonnée côté cuivre.

Goulot n°2 : la puissance PoE réellement disponible (par port et au total)

Le PoE n’est pas seulement une question « d’allumage » : c’est une ressource de conception. Deux vérifications sont indispensables :

  • Limite par port : le port délivre-t-il le type de PoE attendu (802.3at ou 802.3bt) ?
  • Budget PoE total : le switch a-t-il la puissance globale pour alimenter tous les ports PoE simultanément selon le scénario projet (et non un scénario idéal) ?

Pour éviter les contresens, gardez en tête que les limites IEEE distinguent la puissance côté switch (PSE) et la puissance disponible côté terminal (PD). Repères de lecture (valeurs maximales normalisées) :

  • 802.3af (Type 1) : jusqu’à 15,4 W au port PSE et ≈13 W disponibles côté PD.
  • 802.3at (Type 2, PoE+) : jusqu’à 30 W au port PSE et 25,5 W disponibles côté PD.
  • 802.3bt (PoE++, Type 3 / Type 4) : jusqu’à 60 W (Type 3 PSE) / ≈51 W (Type 3 PD) et 90 W (Type 4 PSE) / 71,3 W (Type 4 PD).
Standard IEEE Type Max au port switch (PSE) Max côté équipement (PD) Point de vigilance projet
802.3af (PoE) Type 1 15,4 W ≈13 W Certains AP « s’allument » mais limitent des fonctions si le constructeur attend au minimum du PoE+.
802.3at (PoE+) Type 2 30 W 25,5 W Plusieurs AP Wi‑Fi 6E/7 fonctionnent, mais peuvent rester en mode restreint (USB/radios) si le modèle vise 802.3bt.
802.3bt (PoE++) Type 3 60 W ≈51 W Souvent requis pour un mode « unrestricted » sur certains AP (selon fabricant).
802.3bt (PoE++) Type 4 90 W 71,3 W À réserver aux terminaux très énergivores (selon périmètre projet).

La méthode complète (allocation, négociation, budget global, marges, recette) est détaillée dans notre article dimensionnement de budget PoE.

Goulot n°3 : le câblage (catégorie, longueur, qualité du canal, exécution)

Le multi‑gig (2.5G/5G) est souvent choisi pour exploiter des câbles existants, mais cela n’autorise pas à négliger la qualité réelle du canal : prises, patchs, panneaux de brassage, rayons de courbure, proximité énergie, faisceaux, repérage… Tout compte.

Point important : 2.5GBASE‑T et 5GBASE‑T ont été conçus pour fonctionner sur du câblage structuré courant (notamment Cat5e/Cat6) — mais la tenue réelle dépend de l’état du lien, des perturbations, de la connectique et d’une recette sérieuse. Sur le terrain, un lien peut aussi « downshifter » (négocier à 1G) si le canal est bruité ou mal exécuté.

En conception (neuf / rénovation), une bonne pratique consiste à décider explicitement :

  • ce que l’on réutilise (et donc ce que l’on s’engage à recetter et corriger),
  • ce que l’on remplace quand l’objectif est une montée en débit « garantie ».

Pour cadrer le choix fibre/cuivre et éviter les usages inadaptés (par exemple attendre du PoE sur un tronçon fibre), voir Fibre ou cuivre dans un bâtiment : où utiliser chacun ?.

Méthode de dimensionnement (orientée “éviter les surprises”)

Étape 1 : partir des fiches techniques des points d’accès (et noter ce qui bride)

Avant de choisir switch et câblage, prenez les fiches techniques des AP réellement pressentis. Pour chaque référence, relevez au minimum :

  • Uplink(s) cuivre : 1G / 2.5G / 5G / 10G, nombre de ports, agrégation éventuelle.
  • PoE accepté : 802.3af / at / bt (et, si indiqué, la classe).
  • Puissance maximale annoncée (et conditions : USB, modules, options actives…).
  • Comportement en PoE “dégradé” : fonctions/radios/ports bridés, USB inactif, modes « staging », etc.

Point de vigilance : certains fabricants documentent plusieurs modes selon l’alimentation disponible. Ce tableau est souvent l’explication d’un projet où « les bornes sont neuves mais le résultat n’est pas là ».

Étape 2 : définir le “profil de port” attendu côté switch d’accès

Une borne Wi‑Fi ne consomme pas uniquement un port Ethernet : elle consomme un profil de port (débit + PoE), sur un nombre de ports cohérent avec le design radio.

Dans un cahier des charges, formalisez donc des profils simples, par exemple :

  • Profil AP “standard” : port multigig + PoE+ (si la borne est conçue pour fonctionner sans restrictions à ce niveau).
  • Profil AP “haute capacité” : port multigig + PoE++ (si le fabricant indique un mode « unrestricted » ou équivalent uniquement en 802.3bt).
Profil de port (exemple CCTP) Ethernet côté AP PoE Risque si sous-dimensionné
AP « rénovation / usage modéré » 1GbE ou 2.5GbE (selon AP) 802.3at (PoE+) Plafond backhaul (si 1GbE) ou fonctions AP bridées (si l’AP vise du bt).
AP « multigig nominal » 2.5GbE (minimum) / 5GbE 802.3at (PoE+) ou 802.3bt selon datasheet Négociation à 1GbE si lien cuivre instable ; mode restreint si PoE insuffisant.
AP « haute densité / Wi‑Fi 7 avancé » 5GbE / 10GbE (selon modèle) 802.3bt (PoE++) Ports bridés, USB/radios désactivés, performances irrégulières ou plafond filaire.

L’intérêt de ces profils est double : (1) clarifier le besoin aux entreprises, (2) empêcher l’achat d’un switch « multigig » qui n’offre pas le bon PoE (ou l’inverse).

Étape 3 : dimensionner le budget PoE comme une ressource “site”, pas comme une ligne de devis

La méthode recommandée côté maîtrise d’ouvrage consiste à calculer un budget par switch, et un budget par baie, en tenant compte :

  • du nombre d’AP par switch (issu du design radio),
  • de la puissance PoE à allouer (et pas uniquement la consommation « moyenne »),
  • des autres terminaux PoE (caméras, téléphones, contrôle d’accès, etc.),
  • de la configuration d’alimentation réellement retenue (alimentation unique, redondance, etc.).

Si vous n’avez pas encore un inventaire exact, la bonne pratique n’est pas d’inventer un chiffre : c’est de formaliser le besoin de fiches techniques par référence et de laisser la puissance découler des données documentées, puis d’exiger une recette.

Étape 4 : décider explicitement de la stratégie câblage pour le multigig

Deux approches existent, et votre projet doit en choisir une (ou une combinaison) en connaissance de cause :

  • Réutiliser l’existant (Cat5e/Cat6) en acceptant une phase de diagnostic/correction si certains liens ne tiennent pas le niveau attendu.
  • Reposer des liaisons sur les zones critiques (par exemple salles de réunion denses, zones événementielles, bornes “phares”), afin de réduire le risque de négociation à la baisse ou d’erreurs.

Cette décision se traite avec le lot câblage (et le DOE) : repérage, certification des liens, et alignement entre plan de ports et plan d’implantation Wi‑Fi.

Étape 5 : vérifier les uplinks et le cœur (éviter l’entonnoir après les AP)

Des ports AP à 2.5G/5G/10G ne suffisent pas si l’architecture crée un entonnoir ailleurs :

  • uplink(s) des switches d’accès vers le cœur,
  • capacité du cœur et des interfaces,
  • chemin vers les services (authentification, DNS/DHCP, portail captif, supervision),
  • et, selon les usages, capacité WAN / Internet.

Dans l’hôtellerie (réseaux convergés), cette cohérence LAN/PoE/uplinks se traite idéalement dans une vue d’ensemble, comme décrit dans Architecture réseau IP d’un hôtel.

Recette : la checklist qui prouve (ou invalide) la performance réelle

Pour éviter les litiges « ça marche mais ce n’est pas au niveau », imposez une recette qui vérifie des éléments mesurables, pas une impression.

Contrôles indispensables (par zone / par typologie d’AP)

  • Débit négocié au port switch : 1G / 2.5G / 5G / 10G selon objectif.
  • PoE négocié : type (af/at/bt), puissance allouée et (si possible) puissance mesurée.
  • Mode de fonctionnement AP : normal vs restreint (et quelles fonctions sont actives).
  • Erreurs Ethernet : CRC, drops, flaps (symptômes d’un canal cuivre problématique).
  • Test de débit LAN (méthode à définir au projet) pour distinguer un goulot Wi‑Fi d’un goulot filaire.
  • Test de roaming en mouvement (si les usages l’exigent).

Recette radio : ne pas s’arrêter aux « barres de Wi‑Fi »

Dans les environnements exigeants, une recette Wi‑Fi sérieuse repose sur une démarche de site survey : couverture, capacité, interférences, zones denses et zones critiques.

Pour structurer cette démarche avant et après installation : Étude radio Wi‑Fi : à quoi sert un site survey ?

Symptômes → diagnostic : reconnaître vite l’origine d’une « borne bridée »

Symptôme : le Wi‑Fi semble bon, mais les débits plafonnent systématiquement

  • Vérifier la vitesse de lien Ethernet négociée sur le port AP (uplink 1 GbE fréquent).
  • Vérifier les uplinks de switch (le goulot peut être en sortie de switch d’étage).
  • Comparer un test local (LAN) et un test vers Internet : sinon, vous confondez limitation WAN et limitation Wi‑Fi.

Symptôme : certaines bornes se comportent différemment (USB/performances/services)

  • Comparer le type PoE négocié entre bornes (802.3at vs 802.3bt).
  • Vérifier le budget PoE global du switch : un port peut “décrocher” en cas de manque de budget à l’allumage ou en charge.
  • Inspecter les politiques d’allocation PoE et la négociation (le comportement dépend de l’écosystème et de la configuration).

Symptôme : négociation aléatoire (2.5G/5G qui redescend à 1G, erreurs)

  • Tester avec un cordon court certifié (isoler la partie patch/cordon).
  • Recertifier le lien complet (channel), et confronter la mesure au DOE.
  • Identifier les chemins problématiques (faisceaux denses, proximité énergie/perturbations, connectique).

Cas Maroc : Wi‑Fi 6E/7, 6 GHz et conformité (à vérifier projet par projet)

Dans les projets au Maroc, il est important de dissocier :

  • la génération Wi‑Fi (6, 6E, 7) et les capacités des AP/terminaux ;
  • les conditions d’usage des bandes (dont le 6 GHz) et les contraintes applicables (indoor/outdoor, puissances, canaux, etc.).

Plutôt que de présumer, la bonne méthode est celle décrite dans notre dossier Wi‑Fi 7 : quand devient-il réellement utile ? : étude radio, pilote, puis décision sur la base de KPI et de la conformité du matériel retenu.

Mini-checklist CCTP / appel d’offres (pour verrouiller les attentes)

  • Pour chaque AP : uplink(s), PoE requis, puissance max, conditions de mode restreint (à joindre en annexe datasheet).
  • Pour chaque switch d’accès : nombre de ports multigig, type PoE par port (at/bt), budget PoE total avec alimentation réellement fournie, uplinks.
  • Pour le câblage : catégorie et homogénéité du canal, livrables de test/certification, repérage et DOE.
  • Pour la recette : PV incluant vitesse de lien, état PoE, erreurs Ethernet, vérifications radio (site survey si nécessaire), et traces/export des états (switch + contrôleur).

Conclusion : une borne Wi‑Fi 6E/7 performe si le bâtiment la “porte” correctement

Éviter les « bornes bridées » n’est pas une affaire de marque ou de logo Wi‑Fi : c’est un alignement entre uplinks multigig, budget PoE, câblage recetté et architecture réseau. La recette (mesurée, documentée) est votre meilleure assurance.

Si vous souhaitez cadrer un projet (bureaux, hôtel, retail) avec une approche orientée exploitation et DOE, découvrez notre page Réseau d’entreprise.

27Nov

Documentation réseau : quels schémas et sauvegardes remettre au client ?

by Domocasa
Guides techniques Réseaux et Wi-Fi

Un réseau peut fonctionner le jour de la livraison et devenir difficile à maintenir six mois plus tard si personne ne sait quel câble dessert une caméra, quels VLAN sont en place ou comment restaurer un switch. Le DOE réseau informatique doit permettre au propriétaire et à un futur mainteneur de comprendre, diagnostiquer et faire évoluer l’installation sans dépendre de la mémoire de l’équipe de chantier.

Read More
17Nov

Deux connexions Internet : comment assurer le failover d’une entreprise ou d’un hôtel ?

by Domocasa
Guides techniques Hôtellerie Réseaux et Wi-Fi

Dans une entreprise ou un hôtel, une coupure Internet peut impacter réservations, paiements, VoIP, cloud et Wi‑Fi client. Un failover efficace ne se limite pas à deux abonnements : il faut diversifier les chemins, détecter les pannes réelles, configurer un routeur multi‑WAN, sécuriser l’alimentation, prioriser les flux et recetter la bascule/retour.

Read More
13Nov

Comment dimensionner une baie réseau professionnelle ?

by Domocasa
Guides techniques Réseaux et Wi-Fi

Une baie réseau trop petite se repère souvent après livraison : brassage encombré, courbes de câbles excessives, alimentation mal répartie et aucune réserve. Dimensionner une baie réseau professionnelle consiste à inventorier les équipements (U, profondeur, poids), anticiper l’alimentation/UPS, la dissipation thermique, le brassage et les conditions d’exploitation pour garder une installation maintenable et évolutive.

Read More
Copyright © 2025 Domocasa. All rights reserved.