Filtrage DNS pour les MSP et les parcs multi-sites

Le filtrage DNS pour les MSP et les réseaux multi-sites vérifie les requêtes de domaine par rapport aux politiques de sécurité dans le cloud avant que les appareils ne se connectent. Géré de manière centralisée via Purple aux côtés des SSID, des Captive Portals et des analyses, il ne nécessite aucun matériel sur site. Fonctionnant via des intégrations telles que Cisco Meraki et HPE Aruba, Purple protège des réseaux couvrant plus de 80 000 sites actifs sans aucun agent.

Qu'est-ce que le filtrage DNS pour les MSP et les réseaux multi-sites ?

Chaque connexion établie par un appareil commence par une recherche DNS (Domain Name System). L'appareil demande à un résolveur de convertir un nom tel que example.com en adresse IP. Le filtrage DNS, également appelé DNS protecteur, vérifie ce nom par rapport à une politique avant de répondre. Si le domaine est malveillant ou non conforme à la politique, le résolveur ne fournit pas la véritable adresse. L'appareil n'ouvre jamais la connexion, donc rien ne se télécharge et aucune page ne s'affiche.

Pour un site unique, c'est un contrôle utile. Pour un fournisseur de services gérés (MSP) ou une équipe informatique multi-site, l'exigence prend une autre forme. Vous filtrez des dizaines ou des centaines de réseaux, appartenant à des clients différents, avec des règles différentes, sur du matériel différent. Cela implique trois exigences qu'un filtre sur site unique satisfait rarement :

• Politique par client (tenant). Un tenant est un client ou une unité commerciale disposant de ses propres règles. Un groupe hôtelier familial, une chaîne de pubs et un cabinet médical ne doivent jamais partager la même politique.
• Gestion centralisée. Vous devez pouvoir visualiser et modifier la politique de chaque tenant depuis un seul endroit, sans avoir à vous connecter à chaque site.
• Aucun matériel par site. L'expédition, l'installation en rack et la mise à jour d'un équipement sur chaque site ne sont pas évolutives à l'échelle d'un parc.

Purple Shield est l'extension de DNS protecteur de Purple, aux côtés de SecurePass et Verify. Le filtrage s'exécute dans le cloud et s'associe aux SSID (noms de réseau), aux Captive Portals et aux analyses que vous gérez déjà pour chaque client. Un Captive Portal est la page de connexion qu'un visiteur voit avant d'accéder à Internet.

En quoi le filtrage pour MSP diffère-t-il d'un déploiement sur un site unique ?

Un filtre sur site unique comporte une seule politique, un seul administrateur et un seul réseau. Un parc MSP comporte une hiérarchie. Vous définissez des règles pour l'ensemble du parc, vous les remplacez par client, puis vous les modifiez par réseau au sein d'un site. Le réseau invités d'un hôtel nécessite des règles différentes de celles du réseau du personnel situé derrière la réception.

Les filtres DNS autonomes gèrent généralement cela à l'aide d'une sous-organisation par tenant, configurée séparément du WiFi lui-même. Vous vous retrouvez à gérer deux structures pour chaque client : une pour le réseau et le portail, et une pour le résolveur. Purple Shield supprime la seconde structure, car la politique de filtrage suit les réseaux que vous avez déjà définis dans Purple.

Pourquoi le filtrage DNS est-il essentiel sur un parc de sites clients ?

Trois contraintes placent le filtrage en tête des priorités des MSP : le devoir de diligence, l'exposition aux menaces et la bande passante limitée.

Devoir de diligence sur les réseaux partagés

Le WiFi public et invité implique de réelles obligations. En Angleterre, les écoles et les établissements d'enseignement supérieur respectent les normes de filtrage et de surveillance du Ministère de l'Éducation, mentionnées dans le guide Keeping children safe in education. Aux États-Unis, la loi CIPA (Children's Internet Protection Act) exige que les écoles et bibliothèques bénéficiant du financement E-rate mettent en place un filtrage. Les hôtels, cafés et centres de loisirs qui accueillent des familles s'exposent à des risques réputationnels si un enfant accède à du contenu pour adultes. Le label britannique Friendly WiFi a été créé précisément pour cette raison.

Lorsque vous gérez le WiFi pour 40 clients, vous partagez une partie de chacune de ces obligations. Un seul site non filtré représente une discussion avec un client que vous préférez éviter.

Des menaces qui atteignent les appareils non gérés

Vous ne pouvez pas installer d'agent sur le téléphone d'un visiteur, et vous ne pouvez pas le mettre à jour. Les liens de phishing, les téléchargements de logiciels malveillants et les rappels de commande et contrôle commencent tous par une requête DNS. Cela fait de cette requête le seul point de contrôle dont vous disposez pour chaque appareil sur le réseau.

Purple Shield signale les menaces dès la phase de requête DNS, bloquant les demandes malveillantes avant que les connexions ne s'établissent. Sur l'ensemble d'un parc, un blocage de menace s'applique simultanément chez chaque client. Pour une vue plus large du marché, consultez Phishing Protection Software: 10 Options for Shared WiFi.

La bande passante sur les sites limités

De nombreux sites font fonctionner le WiFi invité sur une liaison montante modeste : un routeur 4G dans une station-service, une ligne partagée dans un pub, un circuit saturé dans une gare. Le trafic publicitaire et les contenus web indésirables entrent en compétition avec le reste. Le filtrage des publicités et des domaines malveillants au niveau de la couche DNS réduit la consommation de données réseau et améliore la vitesse de chargement. Sur un site encombré, cette marge libérée profite au trafic recherché par les invités.

Ce qu'un pare-feu ne voit pas

Un pare-feu reste essentiel, mais il intervient à un autre niveau. Il inspecte les connexions une fois que le DNS a déjà répondu. Cela laisse quatre failles sur un parc invité multi-site :

1. Le chiffrement masque la destination. TLS 1.3 (RFC 8446) chiffre le certificat du serveur. Encrypted Client Hello (ECH), une extension IETF de TLS, peut également masquer le nom du serveur. Sans déchiffrement, un pare-feu ne voit qu'une adresse IP et peu d'autres éléments, et vous ne pouvez pas installer de certificat de déchiffrement sur l'appareil d'un visiteur.
2. Les adresses IP partagées floutent les règles. Les réseaux de diffusion de contenu (CDN) hébergent de nombreux domaines sur les mêmes adresses. Bloquez l'IP et vous bloquez des sites légitimes ; autorisez-la et le domaine malveillant passe.
3. Les jeux de règles par site divergent. Un parc constitué au fil des ans mélange les fournisseurs de pare-feu et les versions de firmware. Maintenir 60 jeux de règles alignés est un travail à plein temps, et un seul site oublié constitue une faille.
4. Le blocage intervient trop tard. Au moment où un pare-feu agit, l'appareil a déjà résolu le nom et tenté une connexion. Le filtrage DNS stoppe la requête avant même qu'une connexion n'existe.

Le filtrage DNS comble ces failles sans déchiffrement, sans agents et sans règles par site. Il ne remplace pas le rôle du pare-feu, qui consiste à segmenter les réseaux et à contrôler les ports.

Comment fonctionne le filtrage DNS auprès de plusieurs clients ?

Ce qui se passe lors de chaque recherche

1. Un invité se connecte au WiFi du client, généralement via un Captive Portal.
2. L'appareil demande un domaine, par exemple à partir d'un lien contenu dans un e-mail de hameçonnage.
3. Purple Shield vérifie le domaine par rapport à la politique attribuée à ce réseau.
4. Si le domaine est autorisé, l'appareil reçoit l'adresse et se connecte normalement.
5. S'il est bloqué, la recherche ne renvoie pas la véritable adresse, de sorte qu'aucune connexion ne s'ouvre.

Comment structurer une politique par client

Le filtrage de contenu par client fonctionne mieux lorsqu'il s'agit d'un petit ensemble de politiques standard, plutôt que d'un ensemble de règles sur mesure par site. Ce modèle s'applique à l'hôtellerie, au commerce de détail et au secteur public :

• Sécurité de base. Les logiciels malveillants, le hameçonnage et les autres catégories de menaces sont bloqués sur tous les réseaux, pour chaque client. Personne n'y déroge.
• Invité famille. La base, plus les contenus pour adultes et inadaptés à l'âge. Convient aux hôtels familiaux, aux bibliothèques, aux centres de loisirs, aux écoles et aux salles d'attente des services de santé.
• Invité adulte. La base avec des règles de contenu plus souples. Convient aux bars, aux établissements nocturnes et aux hôtels d'affaires.
• Personnel. La base plus des règles reflétant la politique d'utilisation acceptable de chaque client.

Attribuez une politique par réseau, puis ajoutez des exceptions clients uniquement là où l'entreprise en a besoin. L'équipe marketing d'un hôtel peut avoir besoin des plateformes sociales qu'une école bloquerait. Quatre politiques et une courte liste d'exceptions sont bien plus faciles à auditer que 60 ensembles de règles créés manuellement.

Comme Purple Shield associe la politique aux réseaux que vous gérez dans Purple, les SSID invités et personnel d'un site peuvent appliquer des politiques différentes. Les réseaux du personnel utilisant le 802.1X, la norme pour le contrôle d'accès au réseau basé sur les ports, conservent leurs contrôles d'identité. Purple Shield ajoute la couche DNS par-dessus.

Gérer un parc à partir d'un tableau de bord unique

La gestion centralisée des politiques DNS n'est rentable que si elle correspond à votre façon de travailler actuelle. Purple Shield se trouve sur la même plateforme Purple que celle qui gère les SSID, les Captive Portals et les analyses de chaque client. Vous ne changez pas de console pour modifier un filtre, et vous ne maintenez pas un second inventaire de sites.

Cela a des conséquences pratiques pour un MSP :

• Intégration. Un nouveau site client dans Purple ne nécessite aucun compte de résolveur distinct.
• Gestion des modifications. Modifiez une politique une seule fois et elle s'applique à tous les réseaux auxquels elle est attribuée.
• Rapports. L'activité de filtrage se trouve à côté des analyses de connexion que vous partagez déjà, de sorte qu'un seul bilan trimestriel couvre le WiFi et la sécurité.

Pourquoi il n'y a rien à expédier

Purple Shield filtre dans le cloud, il n'y a donc aucun équipement matériel à acheter, configurer, expédier ou remplacer sur chaque site. Purple est indépendant du matériel et fonctionne comme une superposition cloud sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks et Fortinet. Un parc client qui mélange les fournisseurs après des acquisitions applique toujours un seul ensemble de politiques. La configuration varie selon le fournisseur, veuillez donc suivre la documentation d'assistance de Purple pour votre matériel.

Purple fonctionne déjà sur plus de 80 000 sites actifs et a enregistré 440 millions de connexions en 2024 (données Purple).

À quoi ressemble le filtrage DNS sur un parc immobilier réel ?

Les trois scénarios ci-dessous sont des synthèses basées sur des configurations immobilières courantes. Le nombre de sites et le matériel sont typiques ; les résultats représentent la réalité opérationnelle de chaque changement.

Scénario 1 : un MSP avec 14 clients dans le secteur de l'hôtellerie et de la restauration

Situation. Un MSP gère le WiFi invités et personnel pour 14 clients du secteur de l'hôtellerie et de la restauration répartis sur 60 sites. L'ensemble comprend des hôtels indépendants, un groupe de 20 pubs et un parc de vacances. Le WiFi et les Captive Portals fonctionnent déjà sur Purple. Le filtrage était géré sur un service DNS distinct, avec un compte et une liste de sites par client.

Ce qui a été fait. Le MSP a migré le filtrage vers Shield et a remplacé 14 ensembles de règles sur mesure par les quatre politiques standard. Les hôtels familiaux et le parc de vacances ont adopté la politique invités famille ; le groupe de pubs a adopté la politique invités adultes. Deux clients ont conservé de courtes listes d'exceptions.

Résultat. Aucun matériel expédié et aucune visite sur site sur l'ensemble des 60 sites. Le MSP a supprimé 14 comptes de filtrage distincts et gère désormais chaque client depuis le tableau de bord Purple qu'il utilisait déjà. Une modification de règle signifie éditer l'une des quatre politiques, et non plus jusqu'à 60 entrées de sites.

Scénario 2 : les bibliothèques et centres de loisirs d'une collectivité

Situation. Un conseil départemental propose du WiFi public dans 22 bibliothèques et cinq centres de loisirs. Les enfants utilisent les réseaux des bibliothèques après l'école. Deux marchés publics ont conduit à l'installation d'HPE Aruba dans les bibliothèques et d'Ubiquiti UniFi dans les centres de loisirs. L'équipe informatique compte trois personnes.

Ce qui a été fait. Le conseil a appliqué la politique invités famille à chaque SSID public et la politique personnel aux réseaux des employés. L'authentification du personnel reste sur 802.1X avec WPA3-Enterprise, la norme actuelle de chiffrement WiFi d'entreprise. Les visiteurs se connectent toujours via le Captive Portal du conseil.

Résultat. Les 27 sites appliquent une politique publique unique sur deux fournisseurs de matériel différents, sans aucun équipement physique supplémentaire. Une seule modification s'applique aux 27 sites. Le conseil présente aux auditeurs une seule politique et une seule source de journaux, au lieu de 27 configurations locales.

Scénario 3 : un réseau de 120 magasins disposant d'une liaison réseau limitée

Situation. Une enseigne de la grande distribution propose un WiFi invités aux clients de 120 magasins, dont un tiers utilise une liaison 4G. La navigation des clients entre en concurrence avec les systèmes du magasin pour la bande passante. L'environnement des données de titulaires de cartes est déjà segmenté du trafic invités pour rester hors du périmètre PCI DSS.

Ce qui a été fait. Le détaillant a activé la protection contre les menaces et le blocage des publicités de Shield sur le SSID invités uniquement. Il a commencé par un pilote sur 10 magasins parmi ses sites 4G les plus fréquentés. Les réseaux du personnel et des systèmes de magasin sont restés sur leurs propres segments.

Résultat. Le pilote a mesuré sa propre utilisation avant et après sur quatre semaines, démontrant une réduction globale de la consommation de données sur les connexions limitées. Le détaillant a ensuite étendu la politique aux 120 magasins en une seule modification, sans aucune visite en magasin.

Où se situe le filtrage DNS par rapport à vos installations existantes ?

Le DNS protecteur constitue une couche de sécurité. Il fonctionne de manière optimale aux côtés des contrôles que vous possédez probablement déjà.

• Segmentation. Les VLANs (réseaux locaux virtuels, qui divisent un réseau physique en réseaux logiques isolés) séparent le trafic des invités de celui du personnel et des systèmes de paiement. Consultez l'article How to Set Up Network Segmentation for Guests and Staff.
• Authentification. La norme 802.1X avec RADIUS, le protocole qui vérifie les identifiants auprès d'un serveur central, détermine qui rejoint le réseau du personnel. C'est également le cas de SecurePass avec Microsoft Entra ID, Okta ou Google Workspace. Shield détermine où les appareils peuvent accéder une fois connectés.
• Pare-feu. Votre pare-feu contrôle toujours les ports, les protocoles et le trafic entre les segments. Shield bloque les destinations malveillantes connues dès la recherche DNS.
• Législation sur la confidentialité. Les journaux DNS peuvent contenir des adresses IP et des identifiants d'appareils, que le GDPR considère comme des données personnelles. Purple est conforme au GDPR et certifié ISO 27001.

Comparaison entre Shield, DNSFilter et Cisco Umbrella

DNSFilter et WebTitan s'adressent fortement aux MSP, et Cisco Umbrella est la solution par défaut dans de nombreux environnements Cisco. Tous effectuent un filtrage au niveau de la couche DNS dans le cloud. Les différences résident dans la gestion : qui gère quoi, et où.

Critère	Purple Shield	DNSFilter	Cisco Umbrella
Lieu du filtrage	Recherche DNS, dans le cloud de Purple	Recherche DNS, dans le cloud de DNSFilter	Recherche DNS, dans le cloud de Cisco
Matériel par site	Aucun	Aucun pour le filtrage réseau	Aucun pour la protection au niveau de la couche DNS
Gestion des clients (tenants)	Dans le tableau de bord Purple qui gère le WiFi client	Console MSP séparée avec sous-organisations	Console multi-organisations ou MSP séparée
Lié aux SSIDs, aux Captive Portals et à l'analyse WiFi	Oui, natif à la plateforme WiFi	Non, configuré comme une pile séparée	S'intègre à Cisco Meraki, géré dans sa propre console
Appareils nomades hors site	Conçu pour les appareils connectés au WiFi que vous gérez	Agent client nomade	Module nomade Cisco Secure Client
Couverture matérielle	Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks, Fortinet	Tout réseau pouvant réacheminer le DNS vers ses résolveurs	Tout réseau pouvant réacheminer le DNS vers ses résolveurs, intégration optimale avec Cisco
Idéal pour	Les MSP dont le WiFi des clients fonctionne sur Purple	Les MSP protégeant les terminaux gérés sur site et hors site	Les environnements standardisés sur la sécurité Cisco

Les solutions alternatives sont performantes là où Shield ne se positionne pas. DNSFilter et Cisco Umbrella proposent tous deux des agents nomades pour les ordinateurs portables gérés hors site. Umbrella s'intègre également dans le portefeuille de sécurité plus large de Cisco. WebTitan, de TitanHQ, propose aussi un filtre cloud multi-clients pour les MSP. Si vos contrats couvrent les terminaux d'entreprise où qu'ils se trouvent, l'une de ces solutions peut convenir.

L'argument de Shield est plus ciblé et, pour les MSP gérant le WiFi, plus solide. Si vous gérez les SSID, le Captive Portal et les analyses de chaque client dans Purple, maintenir une pile de résolveurs distincte par client représente une charge inutile. Pour plus de détails, consultez Shield vs DNSFilter : comparaison du DNS protecteur pour les opérateurs WiFi et Shield vs Cisco Umbrella : choisir un DNS protecteur pour le WiFi invité.

Quelles sont les limites du filtrage DNS à connaître ?

Le filtrage DNS intervient à un point précis d'une connexion, ce qui définit ses limites.

• Le DNS chiffré peut le contourner. Le DNS sur HTTPS (DoH, RFC 8484) et le DNS sur TLS (DoT, RFC 7858) permettent à un appareil de choisir son propre résolveur. Les contrôles réseau peuvent réduire cela sur les appareils non gérés, mais ne peuvent pas l'éliminer. Voir Le DNS sur HTTPS expliqué : confidentialité vs filtrage du WiFi public.
• Les VPN créent des tunnels qui le contournent. Un invité utilisant un VPN personnel résout les noms à l'intérieur du tunnel. Vous pouvez bloquer les domaines VPN connus, mais pas la totalité.
• Les connexions IP directes ignorent le DNS. Un logiciel malveillant appelant une adresse IP codée en dur n'effectue jamais de recherche DNS. Votre pare-feu gère ce cas de figure.
• Il voit les domaines, pas le contenu. Le filtrage DNS autorise ou bloque un domaine entier, pas des pages ou des fichiers individuels.
• Les catégories nécessitent une révision. Toute liste de catégories peut parfois bloquer de manière excessive ou insuffisante. Attribuez à chaque client un contact désigné et une procédure pour demander des modifications.
• Les journaux nécessitent une gouvernance. Convenez de la conservation et de l'accès par client avant le déploiement, et consignez-le dans votre accord de traitement des données.

Que devez-vous faire ensuite ?

1. Cartographiez vos clients. Listez chaque client, site et réseau, avec leurs obligations sectorielles et réglementaires telles que les écoles, les bibliothèques, les établissements de santé et les lieux sous licence.
2. Rédigez des politiques standards. Commencez par les quatre ci-dessus et maintenez la ligne de base de sécurité obligatoire.
3. Faites un pilote sur des sites représentatifs. Choisissez un site par secteur d'activité, y compris un site avec une liaison montante limitée, et mesurez l'utilisation des données avant et après.
4. Déployez par politique, non par site. Attribuez des politiques aux réseaux pour chaque client, puis examinez les exceptions après 30 jours.
5. Faites un retour d'information. Ajoutez l'activité de filtrage aux rapports WiFi que vous fournissez déjà.

Si le WiFi de vos clients ne fonctionne pas encore sur Purple, commencez par Guest WiFi, puis ajoutez Shield. Pour en savoir plus sur la sécurisation des réseaux sur l'ensemble de vos parcs, parcourez tous les guides.

Foire aux questions

Dois-je installer du matériel sur chaque site client pour utiliser le filtrage DNS ?

Non. Shield filtre au niveau de la couche DNS dans le cloud, il n'y a donc aucun équipement à acheter, configurer ou expédier sur site. Purple fonctionne comme une superposition cloud sur les points d'accès que vos clients possèdent déjà, notamment Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks et Fortinet. La configuration varie selon le fournisseur, veuillez donc suivre la documentation d'assistance de Purple pour chaque type de matériel de votre parc.

Puis-je définir des politiques de filtrage différentes pour chaque client et chaque réseau ?

Oui. Shield associe la politique de filtrage aux réseaux que vous exploitez déjà dans Purple, afin que chaque client et chaque SSID au sein d'un site puisse appliquer sa propre politique. Le réseau invités d'un hôtel peut bloquer le contenu pour adultes tandis que son réseau personnel applique les règles d'utilisation acceptable du client. Un ensemble restreint de politiques standardisées, associé à de courtes listes d'exceptions, est plus facile à auditer que des règles sur mesure par site.

Puis-je gérer le filtrage de contenu pour plusieurs sites à partir d'un seul tableau de bord ?

Oui. Shield est géré au sein de la même plateforme Purple que celle qui gère les SSID, les portails captifs et les analyses de vos clients, ce qui vous permet de modifier le filtrage sans changer de console. Une modification de politique s'applique à tous les réseaux attribués à cette politique, sur l'ensemble des sites. L'activité de filtrage figure aux côtés de vos rapports WiFi existants, permettant ainsi d'évaluer la connectivité et la sécurité lors d'une seule revue client.

Comment Shield se compare-t-il à DNSFilter pour un MSP ?

Shield convient aux MSP dont le WiFi des clients fonctionne déjà sur Purple, tandis que DNSFilter convient aux MSP protégeant les ordinateurs portables gérés sur site et hors site. Les deux filtrent au niveau de la couche DNS dans le cloud, sans matériel par site. DNSFilter fonctionne comme une console multi-locataire séparée avec un agent itinérant. Shield fonctionne au sein de la plateforme WiFi, lié aux mêmes SSID, portails captifs et analyses que vous gérez déjà.

Les invités peuvent-ils contourner le filtrage DNS avec le DNS over HTTPS ou un VPN ?

Oui, un utilisateur déterminé le peut. Le DNS over HTTPS, le DNS over TLS et les VPN personnels envoient des requêtes en dehors de votre résolveur. Des contrôles réseau peuvent réduire cela, par exemple en bloquant les points de terminaison VPN et DoH publics connus, mais aucun filtre DNS ne contrôle totalement un appareil non géré. Considérez le filtrage DNS comme la protection par défaut de chaque appareil utilisant le DNS du réseau, en complément de la segmentation et de votre pare-feu.

Le filtrage DNS aide-t-il les écoles et les bibliothèques à respecter les exigences de filtrage ?

Il couvre l'élément de filtrage, mais le filtrage seul ne répond pas à l'ensemble des exigences. En Angleterre, les normes de filtrage et de surveillance du Ministère de l'Éducation exigent à la fois le filtrage et la surveillance, avec des responsabilités désignées et un examen régulier. Aux États-Unis, la CIPA exige que les écoles et bibliothèques financées par le programme E-rate utilisent des mesures de protection technologiques dans le cadre d'une politique de sécurité Internet. Associez un filtrage cohérent entre les sites à vos processus de surveillance et de protection.

Comment les journaux de requêtes DNS sont-ils gérés selon le GDPR ?

Purple est conforme au GDPR et possède la certification ISO 27001. Les journaux DNS peuvent inclure des adresses IP et des identifiants d'appareils, que le GDPR traite comme des données à caractère personnel. Convenez de la conservation, de l'accès et des finalités avec chaque client avant le déploiement, et consignez ces conditions dans votre accord de traitement des données. En tant que MSP, vous agirez souvent en tant que sous-traitant pour vos clients, veillez donc à documenter qui contrôle les journaux de chaque parc.

Comment Shield est-il facturé pour un parc multi-sites ?

Shield est un module de sécurité complémentaire pour la plateforme Purple, au même titre que SecurePass et Verify. Vous l'ajoutez donc aux sites qui fonctionnent déjà sur Purple. Il n'y a aucun matériel par site, ce qui signifie qu'il n'y a aucun coût d'équipement, d'expédition ou de remplacement à prévoir. Demandez les tarifs à Purple en fonction de votre nombre de clients et de sites, et incluez tous les sites que vous prévoyez d'intégrer cette année.