Le conseil le plus courant dans le débat opposant single tenant vs multi tenant est aussi le moins utile : le single tenant est sécurisé, le multi tenant est économique, et la décision se résume à une grille d'évaluation des achats. Cette approche échoue dans les bâtiments où la conception du réseau a le plus grand impact commercial.
Dans un hôtel, une résidence étudiante, un immeuble locatif, un campus hospitalier ou un espace de travail flexible, la question décisive est de savoir qui contrôle la limite du réseau. Une plateforme dédiée peut toujours laisser fuiter du trafic en raison d'une mauvaise politique. Une structure physique partagée peut protéger chaque locataire lorsque l'identité, l'authentification, le routage et la révocation sont correctement conçus. Le nombre de locataires n'est qu'une étiquette. Le contrôle des limites est l'architecture.
Les données sur le logement au Royaume-Uni rendent cette distinction difficile à ignorer. Une analyse du gouvernement a identifié 459 262 projets immobiliers qui sont ou pourraient être à régime d'occupation mixte, contenant 3,33 millions de logements sociaux, soit 79 % des 4,21 millions de logements sociaux répertoriés dans les statistiques officielles du logement. Pourtant, le ratio moyen de locataires sociaux était de 80 %, tandis que la médiane était de 97 %, ce qui démontre que les projets immobiliers peuvent combiner plusieurs régimes d'occupation tout en restant fortement concentrés sur un seul type d'occupation. Les appartements construits à cet effet représentaient 54 % des projets immobiliers multifamiliaux identifiés, avec un ratio médian de locataires sociaux de 91 %, contre 50 % pour les appartements convertis. La configuration de la propriété modifie le problème de la limite opérationnelle, et pas seulement le contrat de location. (Analyse du gouvernement britannique sur la mixité des régimes d'occupation dans le logement social anglais)
Pourquoi la question du Single Tenant par rapport au Multi Tenant dépasse largement le cadre du SaaS
Les équipes d'entreprise héritent souvent de cette discussion lors de l'achat de SaaS. Elles comparent les instances dédiées aux infrastructures d'applications partagées, puis supposent que la même conclusion s'applique à un bâtiment physique. Ce n'est pas le cas. Dans les propriétés partagées, la question la plus importante est de savoir si l'opérateur peut maintenir un résident, un visiteur, un service ou un sous-traitant dans les limites d'accès et de politiques appropriées.
Un déploiement mono-locataire offre généralement aux ingénieurs une séparation physique plus nette. Cela facilite la portée de l'audit, le contrôle des modifications et le confinement des pannes. Cela n'élimine pas pour autant le risque opérationnel. Un contrôleur mal patché, des identifiants d'administrateur faibles, une règle de pare-feu mal configurée ou un service d'authentification mal défini peuvent compromettre un environnement dédié tout aussi facilement qu'un environnement partagé.
Le réseau multi-locataire crée une responsabilité différente. L'opérateur partage les points d'accès, les commutateurs, les contrôleurs, les liaisons montantes et souvent le plan de gestion, puis utilise des contrôles logiques pour séparer les utilisateurs. Ces contrôles doivent fonctionner à travers les couches sans fil, d'authentification, de routage, de DNS, de surveillance et d'assistance. Un locataire n'est pas isolé simplement parce qu'il dispose d'un SSID ou d'un Captive Portal différent.
La limite pratique n'est pas l'SSID. C'est la chaîne complète allant de l'identité à l'autorisation, au transfert de trafic, à la télémétrie et à la révocation.
Trois limites à tester
Considérez l'architecture à travers trois questions distinctes :
- Limite physique : Quels points d'accès, commutateurs, contrôleurs, circuits et équipements sont partagés ?
- Limite d'identité : Comment le réseau sait-il quel individu, appareil, chambre, service ou entreprise se connecte ?
- Limite de gestion : Qui peut créer des identifiants, modifier les politiques, inspecter la télémétrie, approuver l'accès et le révoquer ?
Cette approche est essentielle dans les réseaux hôteliers et résidentiels, car les utilisateurs se moquent de savoir si le fournisseur qualifie l'architecture de cloud-native, partagée ou dédiée. Ils s'attendent à ce que leurs appareils se connectent facilement et à ce que les appareils de leurs voisins restent séparés. Le personnel s'attend à ce que l'accès disparaisse lorsque leur compte d'annuaire est désactivé. Les opérateurs s'attendent à un flux de travail d'assistance unique plutôt qu'à un parc d'infrastructures distinct pour chaque chambre ou occupant.
La politique de sécurité incendie du Royaume-Uni offre un parallèle utile. Le Fire Safety Act 2021 a précisé que le Fire Safety Order s'applique à la structure, aux murs extérieurs, aux balcons et aux portes d'entrée des appartements dans les bâtiments résidentiels multi-occupés comportant deux ensembles de locaux domestiques ou plus. Les réglementations associées sont entrées en vigueur le 23 janvier 2023, tandis que les contrôles historiques des HMO se sont développés après de graves incendies et ont officialisé une catégorie de risque distincte pour les bâtiments multi-occupés. (Recherche du gouvernement britannique sur le régime mixte et le contexte de la sécurité incendie)
La leçon pour les architectes réseau est directe. L'occupation partagée mérite des contrôles explicites, mais la solution n'est pas automatiquement du matériel dédié. Il s'agit d'une limite démontrable qui correspond au risque, au modèle commercial et à la capacité opérationnelle du bâtiment.
Explication des architectures mono-tenant et multi-tenant
En réseau, l'expression single tenant signifie qu'une seule organisation ou occupant dispose d'une pile d'infrastructure dédiée ou d'une instance opérationnelle dédiée. Cela peut inclure des points d'accès, des contrôleurs, des VLANs, des domaines d'authentification, une surveillance et des autorisations de gestion distincts. Cette conception limite les dépendances partagées, ce qui rend l'environnement plus facile à appréhender lorsque l'organisation possède chaque terminal et décision de politique.
Un groupement hospitalier, un site de défense ou un campus d'entreprise peut choisir ce modèle pour le trafic central car ses processus internes d'identité, de conformité et de réponse aux incidents nécessitent un parc étroitement contrôlé. Une infrastructure dédiée peut également prendre en charge une planification radio sur mesure, des exigences d'appareils inhabituelles et des fenêtres de changement qui seraient difficiles à coordonner entre des locataires non liés.
Le réseau multi tenant utilise une infrastructure physique commune tout en appliquant des contrôles logiques par organisation, foyer, chambre, département ou service. Les VLAN, les VRF, les attributs RADIUS, les clés privées pré-partagées basées sur l'identité (iPSK), les politiques de pare-feu et les moteurs de politique peuvent créer des contextes d'accès distincts sans dupliquer chaque équipement.
Le réseau physique est partagé. Le contexte de sécurité et l'expérience utilisateur ne doivent pas l'être. Une chaîne hôtelière peut exploiter une plateforme gérée de manière centralisée pour l'ensemble de ses établissements, tandis qu'un fournisseur de logements étudiants peut associer chaque résident ou unité à un contexte de politique et d'identifiants distinct.
Réseau mono-tenant vs multi-tenant en un coup d'œil
| Dimension | Single Tenant | Multi Tenant |
|---|---|---|
| Isolation physique | Infrastructure dédiée ou instance opérationnelle | Commutateurs, points d'accès, contrôleurs ou circuits partagés |
| Isolation logique | Généralement plus simple car moins de tenants partagent l'environnement | Essentielle, appliquée via l'identité, les VLAN, les VRF, les règles de pare-feu et les politiques |
| Plan de gestion | Dédié ou strictement limité à une seule organisation | Centralisé, avec une administration tenant-aware et des autorisations déléguées |
| Évolution des coûts | Répète l'infrastructure et le travail opérationnel pour chaque tenant | Partage l'infrastructure et concentre la gestion |
| Contexte typique | Entreprise réglementée, défense, cœur de santé, parc d'entreprise dédié | Hôtellerie, logements étudiants, BTR, services managés, espaces de travail partagés |
| Principal mode de défaillance | Les parcs dupliqués s'écartent les uns des autres ou manquent de maintenance | Une erreur de politique ou d'identité peut affecter plusieurs tenants |
Les équipes qui comparent les modèles de déploiement peuvent utiliser ce guide d'architecture WiFi multi-tenant comme référence pratique, mais la conception doit tout de même être testée par rapport au bâtiment réel et au modèle opérationnel.
Le choix n'est pas entre sécurisé et non sécurisé. Il s'agit de choisir entre la séparation physique avec une duplication plus élevée et la séparation logique avec des exigences de conception et de gouvernance plus élevées.
Comparatif détaillé selon les critères essentiels
La décision d'architecture dépend du bâtiment et du modèle d'exploitation, et non du label SaaS. Un réseau de santé, une résidence étudiante, une propriété de logement locatif et un hôtel peuvent tous fournir du WiFi comme un service public, pourtant leurs limites de défaillance acceptables, leurs responsabilités d'assistance et leurs flux de trafic diffèrent.
Choisissez le single tenant lorsqu'un dysfonctionnement doit rester confiné au sein du parc physique d'une seule organisation. Les ingénieurs peuvent modifier un contrôleur, un pare-feu ou un service d'authentification sans avoir à coordonner une fenêtre de maintenance partagée. Cet avantage ne dure que si chaque environnement dédié bénéficie d'une application appropriée des correctifs, d'une surveillance, d'une documentation et de tests de reprise. Une infrastructure dédiée offre le contrôle, pas la résilience automatique.
Choisissez le multi tenant lorsqu'un seul opérateur doit fournir un service reproductible à travers de nombreux occupants ou propriétés. Une structure partagée prend en charge une politique standard, une supervision centrale et un accueil uniforme des utilisateurs. L'opérateur assume alors une charge de gouvernance plus importante : les identifiants, le trafic, la télémétrie et l'accès administratif doivent rester correctement limités pour chaque tenant.
Cinq critères qui décident de la conception
| Critère | Single Tenant | Multi Tenant | Point d'ancrage |
|---|---|---|---|
| Isolation | La séparation physique limite le rayon d'impact partagé | La séparation logique doit être maintenue à travers chaque couche de contrôle | La force de l'isolation augmente avec le degré de séparation, du schéma partagé à la base de données par tenant |
| Sécurité | Moins de dépendances partagées créent une limite d'audit plus claire | Les contrôles centralisés améliorent la cohérence, mais une seule erreur de politique peut affecter plusieurs tenants | La sécurité dépend de l'assurance d'identité, de la configuration, des correctifs et de la surveillance, et non de l'étiquette de l'architecture |
| Coût | Le matériel, les licences, les canaux de support et la maintenance se répètent pour chaque tenant | L'infrastructure partagée améliore l'utilisation et réduit le travail répétitif | Le coût par tenant augmente à mesure que l'isolation s'accroît. Le comparatif détaillé des coûts apparaît dans la section suivante (Comparaison de l'architecture SaaS au Royaume-Uni) |
| Performance | La capacité dédiée évite les conflits de ressources entre les tenants | La capacité partagée nécessite un contrôle d'admission, une QoS et une surveillance active | L'opérateur a besoin de contrôles explicites pour les voisins bruyants et les appareils à forte demande |
| Opérations | Chaque environnement peut être plus simple, mais le parc devient répétitif | Une seule plateforme peut fonctionner efficacement, à condition que l'automatisation de l'identité et des politiques soit mature | Le Single Tenant concentre le travail opérationnel par environnement. Le Multi Tenant le concentre dans la gouvernance et le plan de contrôle |
L'isolation est une propriété de conception
Testez l'isolation à travers les flux de trafic, pas les schémas. Un résident peut-il découvrir l'appareil d'un autre résident ? Un client peut-il accéder aux services du personnel ? Un administrateur de support peut-il consulter les données de session d'un autre locataire ? Une identité révoquée perd-elle immédiatement l'accès, y compris depuis des appareils préalablement autorisés ?
Les mêmes tests s'appliquent aux deux modèles. Un contrôleur dédié n'y répond pas automatiquement, et un contrôleur partagé ne les rend pas impossibles. La question décisive est de savoir où s'applique la politique, comment les administrateurs sont limités dans leur champ d'action, et quelle quantité d'infrastructure commune se trouve sous chaque locataire.
Dans les résidences étudiantes et le BTR (Built-to-Rent), les résidents s'attendent à un accès privé même si le bâtiment partage la commutation, le sans-fil et la connectivité amont. Les hôtels font face à la même frontière entre les services pour clients, le personnel et les opérations. Le secteur de la santé ajoute les équipements cliniques gérés et les systèmes hérités, le modèle de politique doit donc protéger ces dépendances sans rendre le support de routine impraticable.
Les performances suivent le modèle de la demande
Les hôtels connaissent une demande concentrée autour de l'enregistrement, des événements et de l'utilisation en soirée. Les logements étudiants combinent une forte densité d'appareils avec un renouvellement fréquent. Le secteur de la santé mélange équipements gérés, appareils personnels et systèmes spécialisés. Le single tenant permet de réserver de la capacité, tandis que le multi tenant peut répondre à la même demande lorsque l'opérateur mesure le temps d'antenne, applique la QoS et sépare le trafic critique de l'usage récréatif.
Le WiFi est désormais un service public de base dans ces propriétés. Une interruption de service affecte l'expérience des résidents, les opérations des visiteurs et les résultats commerciaux, et non pas seulement un tableau de bord technique.
Le test pratique est simple : l'opérateur peut-il observer la saturation avant que les utilisateurs ne la signalent, identifier le tenant ou le service responsable, et modifier la politique sans reconstruire le réseau ? Si ce n'est pas le cas, le modèle d'isolation sélectionné est incomplet.
Coût, évolutivité et frais généraux cachés de l'isolation
Une infrastructure dédiée semble simple dans un plan de projet. Chaque locataire reçoit ses propres contrôleurs, commutateurs, points d'accès, licences, intégrations de surveillance, référentiels d'identité, calendriers de firmware et processus de support. La facture inclut le temps d'ingénierie nécessaire pour déployer, documenter, tester, corriger et restaurer chaque copie.
La conception à locataire unique duplique également le travail opérationnel. Les ingénieurs maintiennent des modèles distincts, examinent des alertes similaires dans différentes consoles, répètent la validation des micrologiciels et préservent des procédures de récupération indépendantes. Cette séparation justifie son coût lorsqu'un locataire a besoin d'une limite de conformité distincte ou de contrôles techniques spécifiques. Elle devient une érosion de marge lorsque chaque locataire reçoit le même service et qu'aucune politique n'impose de séparation physique.
La comparaison des coûts précédente s'applique toujours, mais les opérateurs de réseau doivent tenir compte de dépenses que les tableaux SaaS ne montrent pas. Une licence de contrôleur distincte peut comporter sa propre portée contractuelle. Chaque plateforme supplémentaire peut nécessiter un accord d'assistance, une fenêtre de maintenance et une validation du micrologiciel avant le déploiement. Les ingénieurs passent également du temps à tester l'authentification, la surveillance, le basculement et le transfert des locataires à travers de multiples environnements. Dans un portefeuille actif de logements étudiants au Royaume-Uni, de BTR ou d'hôtellerie, ces heures affectent la marge de service aussi directement que le matériel.
Répartition des coûts par client
| Poste de coût | Single Tenant, par tenant | Multi Tenant, par tenant | Notes |
|---|---|---|---|
| Infrastructure physique | Dédiée ou pile réservée | Allocation de structure partagée | Le single tenant duplique les équipements et les travaux sur site |
| Licences de contrôleur et de plateforme | Instance distincte ou portée de licence | Plateforme partagée, licences adaptées au tenant | Les conditions contractuelles peuvent modifier le résultat |
| Identité et authentification | Royaume distinct ou intégration dédiée | Service partagé avec politiques ciblées | Le multi tenant nécessite une cartographie forte des tenants |
| Supervision | Tableaux de bord et chemins d'alerte distincts | Tableau de bord central avec filtres par tenant | Un mauvais filtrage peut créer un risque de contrôle d'accès |
| Support et gestion du changement | Fenêtres et guides opérationnels spécifiques au tenant | Flux de travail standardisés avec exceptions | La standardisation n'améliore l'échelle que lorsque la politique est mature |
| Restauration et tests | Plans de restauration distincts | Restauration de plateforme partagée plus validation du tenant | L'opérateur doit prouver la restauration au niveau du tenant |
Une plateforme partagée ne réduit la duplication que si l'opérateur peut appliquer les limites des locataires de manière cohérente. Elle nécessite des modèles de politique, un déploiement progressif, une validation de configuration, des journaux d'activité limités au locataire et des rollbacks testés. Sans ces contrôles, une console partagée peut transformer un problème d'isolation en un problème de contrôle d'accès.
La conception du réseau doit être testée avant les modifications de production. Les équipes peuvent utiliser un iPSK subnet designer pour modéliser la segmentation basée sur l'identité, vérifier l'allocation des sous-réseaux et détecter tôt les conflits d'adresses ou de politiques.
Payez pour une isolation physique lorsque l'activité exige une limite physique. Ne payez pas pour cela simplement parce que l'équipe de conception n'a pas construit une limite logique digne de confiance.
La bonne réponse est souvent hybride. Conservez le trafic clinique, de paiement, de gestion technique du bâtiment ou d'entreprise sur un chemin dédié étroitement contrôlé. Utilisez un réseau partagé, prenant en compte les locataires, pour les invités, les résidents, les sous-traitants et les autres populations variables. Cette répartition place l'isolation là où une défaillance entraîne des conséquences commerciales, réglementaires ou de sécurité, tandis que l'infrastructure partagée gère la demande qui bénéficie d'un effet d'échelle.
Scénarios réels pour l'IT d'entreprise et les opérateurs réseau
La décision d'architecture devient plus claire lorsque le propriétaire, l'utilisateur et l'impact des pannes sont définis. Un réseau pour une seule organisation n'est pas automatiquement un problème de single-tenant, et un réseau desservant de nombreuses personnes n'est pas automatiquement un problème de multi-tenant.
Scénario un, un campus d'entreprise de 5 000 places
Un grand campus d'entreprise ayant des exigences strictes en matière de résidence des données devrait opter par défaut pour le single-tenant pour les services de base. Le facteur décisif n'est pas l'effectif. C'est la nécessité d'aligner les limites physiques, administratives et d'audit.
Des contrôleurs dédiés, des services d'authentification, des accès de gestion et des chemins de trafic facilitent la démonstration de la conformité. Les équipes de sécurité peuvent restreindre l'accès administrateur au seul personnel de l'organisation, définir un processus de changement unique et enquêter sur les incidents sans filtrer l'activité non liée d'autres locataires.
L'accès invité peut toujours utiliser un service logique distinct. Le réseau principal des employés ne doit pas dépendre de la même trajectoire de politique que les visiteurs temporaires, les prestataires ou les participants à des événements.
Scénario deux, un groupe hôtelier multi-sites
Un groupe hôtelier exploitant des propriétés sous une seule marque devrait généralement choisir le multi tenant. Un centre d'opérations réseau centralisé a besoin d'un onboarding, d'une politique de Captive Portal, de rapports et d'une réponse aux incidents cohérents dans les hôtels, les restaurants et les sites. Dupliquer l'ensemble du parc de gestion dans chaque propriété rendrait la standardisation plus difficile, et non plus sûre.
La frontière doit toujours exister au niveau de la propriété, des invités, du personnel et des services. Les appareils des invités ne doivent pas pouvoir atteindre les systèmes de point de vente. Les identités du personnel ne doivent pas hériter des autorisations des invités. Une équipe locale doit voir les informations requises pour son travail sans obtenir un accès illimité à chaque site.
Le compromis est clair. Le contrôle centralisé l'emporte, à condition que l'opérateur puisse imposer une administration et une politique de trafic adaptées à chaque tenant.
Scénario trois, BTR au Royaume-Uni et logements étudiants
Dans l'immobilier locatif géré (BTR) et les résidences étudiantes dédiées, un modèle multi-tenant hybride s'impose généralement. Les résidents s'attendent à une confidentialité au niveau de l'appartement ou de la chambre, mais l'opérateur bénéficie d'un seul réseau physique à l'échelle de la propriété, d'un modèle d'assistance unique et d'une gestion centralisée des services.
Les données sur le logement étudiant au Royaume-Uni indiquent que 93 % des bailleurs interrogés en Écosse utilisent un contrat de location unique, tandis que 7 % utilisent des contrats de location multiples. Cela suggère que la simplicité administrative influence encore fortement les modèles d'exploitation. (Données sur le logement étudiant au Royaume-Uni)
La connectivité dans ces bâtiments est de plus en plus un service fourni par l'opérateur plutôt qu'un contrat individuel signé par chaque résident. Dans le National Student Accommodation Survey 2026 de Save the Student, 80 % des étudiants ont déclaré que leur loyer couvrait au moins un service supplémentaire, et 48 % ont indiqué que le haut débit était inclus, juste derrière l'eau (63 %), l'électricité (61 %) et le gaz (54 %). L'offrir de manière fiable s'avère toutefois être la partie la plus difficile : l'enquête 2024/25 de Jisc menée auprès de 15 398 étudiants de l'enseignement supérieur au Royaume-Uni a révélé que 60 % d'entre eux signalaient des problèmes de connexion WiFi sur le campus ou en dehors. (Save the Student, National Student Accommodation Survey 2026; Jisc Digital Experience Insights 2024/25)
Le réseau doit donc offrir une expérience privée sans transformer chaque résident en un projet d'infrastructure distinct. L'accès basé sur l'identité, les politiques par unité, la facturation simple et la révocation immédiate importent plus que le label de l'architecture.
Assurer l'isolation des clients sans dupliquer le réseau
Les réseaux modernes basés sur l'identité offrent une troisième option entre une infrastructure physique par locataire et un réseau partagé non contrôlé. L'opérateur partage l'infrastructure, puis associe l'accès à l'identité d'un individu, d'une unité, d'une chambre, d'un département ou d'un appareil.
L'iPSK est un point de départ pratique pour les environnements résidentiels et multi-appareils. Au lieu de délivrer un mot de passe partagé unique à tout un bâtiment, l'opérateur attribue des clés privées distinctes et les associe à un contexte de politique. Une clé peut identifier un appartement, une chambre, un résident, un groupe d'appareils ou une classe de service, selon les besoins opérationnels.
Construire le plan de contrôle par couches
- Associer l'identité à l'accès. Utilisez les attributs RADIUS, les groupes d'annuaires ou un service d'identité géré pour associer un utilisateur ou un appareil à la bonne politique de locataire.
- Appliquer des contrôles basés sur les rôles. Le personnel, les résidents, les invités, les prestataires et les systèmes du bâtiment doivent recevoir des autorisations différentes. Les équipes évaluant cette couche peuvent consulter un logiciel de contrôle d'accès basé sur les rôles pour une explication plus large de la politique par rôle.
- Séparer le trafic. Utilisez des VLAN, des VRF, des règles de pare-feu et des politiques de service pour bloquer les mouvements latéraux entre les locataires et protéger les systèmes opérationnels.
- Automatiser les événements du cycle de vie. Configurez l'accès lorsqu'un résident ou un employé est approuvé, et révoquez-le lorsque l'annuaire ou le registre de gestion immobilière change.
- Définir la portée de la télémétrie. La surveillance centralisée doit fournir aux opérateurs des données de santé utiles sans exposer l'identité ou les informations de session d'un locataire à un autre.
Le SSO via Microsoft Entra ID ou Okta peut lier l'accès d'entreprise à la gouvernance d'identité établie. Cela fonctionne parfaitement pour le personnel et les utilisateurs gérés. L'iPSK reste utile pour les résidents, les visiteurs, les anciens appareils et les équipements qui ne peuvent pas effectuer un flux d'authentification d'entreprise moderne.
La plateforme de réseau basée sur l'identité de Purple est un exemple d'approche par plan de contrôle qui prend en charge l'accès spécifique aux locataires sur une infrastructure partagée, y compris iPSK et les intégrations avec les fournisseurs d'identité d'entreprise. Sa valeur dans cette architecture ne réside pas dans l'existence d'un autre SSID. C'est la capacité de connecter l'identité, la politique, l'intégration et la révocation sans nécessiter un réseau physique distinct pour chaque occupant.
La conception nécessite toujours des tests. Validez qu'un identifiant ne peut pas contourner sa politique d'accès prévue, que l'enregistrement des appareils ne contourne pas la segmentation, que les administrateurs ont des autorisations limitées à leur locataire, et que la révocation atteint les sessions actives. Un réseau physique partagé peut offrir une expérience de locataire privé, mais seulement lorsque l'opérateur traite l'identité et la politique comme une infrastructure de production.
Quelle architecture choisir et à quel moment
Utilisez le single tenant lorsque l'organisation a besoin d'une limite physique dédiée, et pas seulement d'un identifiant de connexion distinct. Le secteur de la santé réglementé, les environnements de paiement, la défense et les charges de travail d'entreprise hautement sensibles doivent commencer par là pour leurs services essentiels. L'architecture simplifie la collecte de preuves et réduit les dépendances partagées, bien qu'elle exige toujours un déploiement rigoureux des correctifs, une surveillance et une gestion des identités.
Utilisez le multi-locataire lorsque l'opérateur sert de nombreux clients, occupants, chambres, services ou propriétés et que le service dépend d'une prestation reproductible. L'hôtellerie, les résidences étudiantes, le secteur résidentiel locatif (BTR), les services gérés et les espaces de travail partagés tirent généralement plus de profits d'opérations centralisées que de la duplication du matériel. La condition préalable est une politique stricte respectueuse de chaque locataire, et non une norme de sécurité relâchée.
Utilisez un modèle hybride lorsqu'un site contient à la fois des services internes hautement sensibles et de grands volumes d'utilisateurs temporaires ou résidentiels.
Matrice de recommandation d'architecture
| Scénario | Modèle recommandé | Pourquoi |
|---|---|---|
| Cœur d'entreprise réglementé, systèmes cliniques de santé ou trafic de paiement | Single tenant | La limite physique et d'audit doit correspondre à la limite de contrôle de l'organisation |
| Fournisseur SaaS ou opérateur de services gérés desservant de nombreux clients | Multi tenant | L'infrastructure partagée prend en charge une politique reproductible, des opérations centrales et une expansion efficace |
| Groupe hôtelier avec services clients centralisés | Multi tenant | Un modèle opérationnel unique garantit la cohérence de l'identité, du support et de la prestation de services entre les établissements |
| BTR, logement étudiant ou espace de travail flexible | Hybride multi tenant | L'infrastructure partagée fonctionne avec une identité, une politique, une facturation et une révocation par occupant |
| Site d'entreprise avec réseaux d'employés et d'invités | Hybride | Maintenez un contrôle strict sur le trafic d'entreprise sensible tout en appliquant un accès invité adapté à chaque tenant |
| Environnement avec incidents répétés de voisinage bruyant ou constatations d'audit | Réévaluer, puis isoler les services concernés | La limite actuelle est défaillante, quel que soit le type d'architecture |
Les décisions de migration doivent suivre la même logique. Inventoriez les classes de trafic, les identités, les types d'appareils, les rôles de gestion et les domaines de défaillance avant de choisir une plateforme. Les signaux d'alerte comprennent une visibilité croisée inexpliquée entre locataires, des politiques incohérentes entre les sites, une révocation d'accès lente, des équipes d'assistance disposant d'une portée administrative excessive, et le désabonnement des locataires dû à des contrôles manquants ou à des retards de fonctionnalités.
Posez-vous une question avant de signer la conception : à qui appartient la limite du réseau, et a-t-on besoin d'un matériel dédié ou d'une politique dédiée ?
Le résumé du document d'orientation est simple :
- Choisissez le single tenant lorsque l'isolation physique est une exigence commerciale ou de conformité.
- Choisissez le multi tenant lorsque l'évolutivité dépend d'une infrastructure partagée et de contrôles d'identité matures.
- Choisissez l'hybride lorsque le trafic central sensible et l'accès partagé à grand volume coexistent.
Purple fournit une connectivité réseau basée sur l'identité pour les bâtiments partagés, y compris des contrôles d'accès au niveau des locataires et une séparation basée sur iPSK sur une infrastructure commune. Visitez Purple pour évaluer si cette approche convient à votre logement étudiant, BTR, hôtellerie, secteur de la santé ou à la conception de votre réseau WiFi invité d'entreprise, puis testez la limite avec vos propres politiques d'identité, de révocation et de trafic.
