Responsabilité liée au WiFi public : pourquoi le filtrage de contenu est obligatoire
Ce guide de référence technique présente les risques juridiques et opérationnels liés à la fourniture d'un WiFi public non filtré, en expliquant pourquoi le filtrage de contenu est une exigence de déploiement obligatoire pour les exploitants de sites. Il fournit des stratégies d'architecture exploitables, des étapes de mise en œuvre et des tactiques de atténuation des risques pour protéger les réseaux contre les activités illégales, les violations de droits d'auteur et le non-respect des réglementations. Les exploitants de sites et les directeurs techniques y trouveront des études de cas concrètes, des cadres de décision et des conseils de configuration pour mettre en œuvre un environnement de Guest WiFi défendable et conforme.
Écouter ce guide
Voir la transcription du podcast
Résumé Exécutif
Pour les responsables informatiques, les architectes réseau et les directeurs techniques supervisant des espaces publics, le déploiement d'un Guest WiFi est une exigence opérationnelle de base. Cependant, fournir un accès direct à Internet sans un filtrage de contenu robuste expose l'établissement à de graves risques juridiques, financiers et de réputation. Lorsque vous fournissez un accès Internet public, votre organisation assume le rôle d'un fournisseur d'accès Internet (FAI). Si un trafic malveillant ou illégal — tel que la violation du droit d'auteur, le piratage peer-to-peer (P2P) ou le matériel d'abus sexuel sur enfant (CSAM) — provient de vos adresses IP publiques, la responsabilité incombe souvent à l'exploitant du site.
Ce guide fournit un cadre technique définitif pour la mise en œuvre d'un filtrage de contenu obligatoire. Nous explorons l'architecture requise pour maintenir les protections de type "safe harbour" (exclusion de responsabilité), garantir la conformité réglementaire (notamment le GDPR et PCI DSS) et préserver les performances du réseau. En intégrant un filtrage robuste avec WiFi Analytics , les établissements des secteurs du Commerce de détail , de l' Hôtellerie , de la Santé et des Transports peuvent atténuer les risques tout en maintenant une expérience client fluide.
Analyse Technique Approfondie
Le Cadre Juridique et le "Safe Harbour"
Le principal moteur du filtrage de contenu est la responsabilité juridique liée au WiFi public. Dans la plupart des juridictions, les FAI et les fournisseurs de WiFi public sont protégés par des dispositions de "safe harbour" — par exemple, le Digital Millennium Copyright Act (DMCA) aux États-Unis, ou la directive sur le commerce électronique et ses cadres successifs dans l'UE. Cependant, ces protections sont explicitement conditionnelles. Pour y prétendre, les fournisseurs doivent démontrer qu'ils ont pris des mesures techniques raisonnables pour empêcher les activités illégales et qu'ils peuvent aider les forces de l'ordre en cas de besoin.
Sans piste d'audit et sans filtrage actif, un établissement ne peut pas prouver qu'il a pris des mesures raisonnables, ce qui annule complètement les protections de "safe harbour". Ceci est particulièrement critique pour les déploiements dans le secteur public, où les exigences de responsabilité sont encore plus strictes. Pour en savoir plus sur l'évolution de l'infrastructure numérique du secteur public, consultez Purple Appoints Iain Fox as VP Growth – Public Sector to Drive Digital Inclusion and Smart City Innovation .
Les trois principaux vecteurs de risque juridique pour les réseaux non filtrés sont :
| Vecteur de Risque | Exposition Juridique | Exemple de Conséquence |
|---|---|---|
| Violation des droits d'auteur (P2P) | Responsabilité civile, ordonnances de cessation et d'abstention | Le titulaire des droits poursuit l'établissement pour facilitation de contrefaçon |
| Distribution de CSAM | Poursuites pénales | Enquête policière, révocation de licence |
| Non-conformité GDPR | Amendes réglementaires jusqu'à 4 % du chiffre d'affaires mondial | Action répressive de l'ICO pour journalisation inadéquate |
Architecture d'un réseau filtré
Un filtrage de contenu efficace nécessite une architecture multicouche. Aucun contrôle unique n'est suffisant. Les couches suivantes doivent fonctionner de concert :
Couche 1 — Authentification (Captive Portal) : Avant que l'accès au réseau ne soit accordé, les utilisateurs doivent s'authentifier. Cela associe un appareil (adresse MAC) et un bail IP à une identité vérifiée via SMS, e-mail ou connexion sociale. C'est le fondement de votre piste d'audit. Pour en savoir plus sur l'importance de cette tenue de registres, consultez Expliquer ce qu'est une piste d'audit pour la sécurité informatique en 2026 .
Couche 2 — Moteur de filtrage DNS : L'approche la plus évolutive pour les environnements à haut débit est le filtrage DNS basé sur le cloud. Lorsqu'un utilisateur demande un domaine, le résolveur DNS vérifie la demande par rapport à une base de données de renseignements sur les menaces en temps réel. Si le domaine est classé comme malveillant ou illégal — logiciels malveillants, contenu pour adultes, trackers de piratage —, la résolution est bloquée et l'utilisateur est redirigé vers une page de blocage conforme à la politique.
Couche 3 — Passerelle de couche applicative (Pare-feu) : Le filtrage DNS seul est insuffisant. Les utilisateurs peuvent contourner les filtres DNS en utilisant des connexions IP directes ou un DNS chiffré (DNS over HTTPS — DoH). La passerelle réseau doit bloquer les résolveurs DoH connus et restreindre les protocoles spécifiques, en particulier les protocoles P2P comme BitTorrent, qui sont le principal vecteur de violation des droits d'auteur sur les réseaux publics.
Couche 4 — Journalisation et piste d'audit : Toutes les données de session — identité authentifiée, adresse MAC, IP attribuée, horodatages et durée de la session — doivent être enregistrées de manière sécurisée et conservées pendant la période légalement requise. Ces données doivent être accessibles aux forces de l'ordre sur demande, sans compromettre les données des autres utilisateurs conformément aux principes du GDPR.
Résoudre le problème du DoH
Le DNS over HTTPS (DoH) est le plus grand défi technique pour le filtrage de contenu en 2025 et au-delà. Les navigateurs modernes — y compris Chrome, Firefox et Edge — peuvent être configurés pour utiliser le DoH par défaut, acheminant les requêtes DNS via HTTPS vers des résolveurs comme Cloudflare (1.1.1.1) ou Google (8.8.8.8). Cela contourne complètement votre couche de filtrage DNS gérée.
La stratégie d'atténuation comporte deux volets :
- Bloquer les IP des résolveurs DoH connus au niveau du pare-feu. Maintenez à jour une liste des points de terminaison DoH connus et bloquez le trafic HTTPS sortant vers ces IP spécifiques.
- Interceptez et redirigez tout le trafic du port 53 vers votre résolveur DNS géré à l'aide de règles NAT de pare-feu, empêchant ainsi le contournement manuel du DNS par les invités.
Guide de mise en œuvre
Le déploiement d'une solution de filtrage robuste nécessite une planification minutieuse afin de concilier sécurité et expérience utilisateur. Les étapes suivantes s'appliquent aux établissements de toutes tailles, qu'il s'agisse d'un hôtel indépendant ou d'une chaîne de Retail multi-sites.
Étape 1 : Définir la politique d'utilisation acceptable
Établissez une politique d'utilisation acceptable (AUP) claire que les invités doivent accepter sur le Captive Portal. La politique de filtrage technique doit refléter cette AUP. Bloquez au minimum : les domaines connus de logiciels malveillants et de phishing ; le CSAM (intégrez des bases de données telles que la liste de blocage de l'Internet Watch Foundation) ; les protocoles de partage de fichiers P2P ; et les contenus pour adultes pour les établissements accueillant des familles.
Étape 2 : Configurer le Captive Portal et l'authentification
Assurez-vous que le Captive Portal impose une authentification. L'accès anonyme est l'ennemi de la piste d'audit. Mettez en place des limites de session et veillez à ce que les durées de bail DHCP soient optimisées pour les environnements à forte rotation. Pour les déploiements dans l' Hospitality , intégrez le système à l'outil de gestion hôtelière (PMS) pour authentifier les invités à l'aide de leur référence de réservation.
Étape 3 : Déployer le filtrage DNS et les règles de passerelle
Intégrez un service de filtrage DNS cloud. Configurez la passerelle réseau pour intercepter toutes les requêtes DNS sortantes sur le port 53 et les forcer à passer par le service de filtrage approuvé. Mettez en œuvre des règles de pare-feu pour bloquer les points de terminaison DoH connus. Configurez des règles au niveau de la couche applicative pour rejeter le trafic des protocoles P2P.
Étape 4 : Autoriser les services critiques (Whitelist)
Assurez-vous que les services critiques de l'établissement sont sur liste blanche avant la mise en service. Si votre établissement utilise des services de localisation ou des outils de navigation — par exemple, Purple Launches Offline Maps Mode for Seamless, Secure Navigation to WiFi Hotspots — assurez-vous que les points de terminaison concernés sont accessibles. Préparez également les équipes d'assistance aux problèmes courants post-déploiement ; le filtrage peut parfois provoquer des anomalies de connectivité, comme décrit dans Solving the Connected but No Internet Error on Guest WiFi .
Étape 5 : Tester et valider
Avant la mise en service, effectuez un test structuré : tentez d'accéder à des catégories bloquées connues depuis un appareil invité, vérifiez que la page de blocage s'affiche, assurez-vous que le journal d'audit enregistre la session et confirmez que le trafic légitime n'est pas affecté.
Bonnes pratiques
Renseignement dynamique sur les menaces : Les listes de blocage statiques deviennent obsolètes quelques heures après leur publication. Assurez-vous que votre moteur de filtrage utilise des renseignements sur les menaces mis à jour en temps réel et en continu pour catégoriser les nouveaux domaines dès leur apparition. Les cybercriminels enregistrent quotidiennement de nouveaux domaines spécifiquement pour contourner les listes statiques. Contrôle granulaire des politiques : Évitez les interdictions générales qui perturbent l'activité légitime. Bloquer tout le streaming vidéo peut être approprié pour un réseau de bureau d'entreprise, mais serait totalement inapproprié pour un hôtel. Définissez des politiques par SSID, par type de site ou par heure de la journée lorsque la plateforme le permet.
Gestion du trafic chiffré : Alors que TLS 1.3 et DoH deviennent la norme, s'appuyer uniquement sur le DNS est insuffisant. Évaluez le matériel capable d'inspecter l'indication du nom du serveur (SNI) comme compromis entre le DPI complet et le filtrage uniquement DNS. L'inspection SNI lit le nom du serveur non chiffré dans la poignée de main TLS sans déchiffrer la charge utile, offrant un blocage par catégorie avec un impact minimal sur le débit.
Journalisation de la conformité : Conservez les journaux de connexion — adresse MAC, IP attribuée, horodatage, identité authentifiée — conformément aux lois locales sur la conservation des données. Sous le GDPR, ne journalisez pas l'historique complet de navigation ; journalisez uniquement les métadonnées de connexion. Assurez-vous que les journaux sont chiffrés au repos et soumis à un contrôle d'accès.
Dépannage et atténuation des risques
Modes de défaillance courants
Le contournement DoH : Les clients utilisant des navigateurs modernes configurés pour utiliser le DNS sur HTTPS contourneront les filtres DNS standard. Atténuation : Maintenez une liste de blocage mise à jour des IP des fournisseurs DoH au niveau du pare-feu et redirigez tout le trafic du port 53 via NAT.
Randomisation MAC : Les appareils iOS et Android modernes randomisent les adresses MAC par SSID, ce qui rompt le suivi traditionnel des appareils. Atténuation : Appuyez-vous sur une authentification basée sur la session liée à la connexion au Captive Portal, plutôt que sur un suivi MAC persistant. L'ID de session, et non l'adresse MAC, devient la clé d'audit.
Sur-filtrage et faux positifs : Un filtrage agressif bloque le trafic légitime, générant des tickets d'assistance et dégradant l'expérience client. Atténuation : Mettez en œuvre un processus d'examen rapide de la liste blanche. Surveillez les journaux de domaines bloqués chaque semaine et ajoutez les faux positifs confirmés à la liste blanche sous 24 heures.
Dérive des politiques entre les sites : Dans les déploiements multi-sites, les politiques gérées manuellement divergent avec le temps. Le site A peut avoir une liste de blocage obsolète tandis que le site B est à jour. Atténuation : Imposez une distribution centralisée des politiques gérée dans le cloud avec contrôle de version. Tous les sites doivent s'aligner sur la même politique de référence.
ROI et impact commercial
Le retour sur investissement (ROI) du filtrage de contenu se mesure principalement en termes d'évitement des risques. Une seule poursuite pour violation de droits d'auteur ou une action coercitive de l'ICO peut coûter des dizaines de milliers de livres sterling — dépassant de loin le coût annuel d'une solution de filtrage. Le tableau ci-dessous illustre la différence de coût :
| Élément de coût | Réseau non filtré | Réseau filtré |
|---|---|---|
| Coût annuel de la solution de filtrage | 0 £ | 2 000 £–15 000 £ (selon l'échelle) |
| Règlement pour violation de droits d'auteur | 10 000 £–100 000 £+ | 0 £ (atténué) |
| Amende GDPR (journalisation inadéquate) | Jusqu'à 4 % du chiffre d'affaires mondial | 0 £ (conforme) |
| Atteinte à la réputation / impact sur la marque | Significatif | Minimal |
| Performances réseau (P2P supprimé) | Dégradées | Améliorées |
De plus, le filtrage améliore les performances globales du réseau. En bloquant le trafic P2P gourmand en bande passante et les botnets de logiciels malveillants, vous préservez le débit pour les invités légitimes, ce qui améliore l'expérience utilisateur et réduit la charge sur l'infrastructure. Associé à une plateforme robuste d' Analyses WiFi , le réseau se transforme, passant d'une responsabilité non gérée à un actif sécurisé et générateur de données qui produit des résultats commerciaux mesurables.
Définitions clés
Safe Harbour
Dispositions juridiques qui protègent les FAI et les opérateurs de réseau de toute responsabilité quant aux actions de leurs utilisateurs, à condition qu'ils prennent des mesures techniques raisonnables pour prévenir les abus et puissent aider les forces de l'ordre.
Le principal bouclier juridique pour les exploitants de sites. Le filtrage de contenu et la journalisation d'audit sont les conditions techniques qui maintiennent le statut de Safe Harbour.
Captive Portal
Une page web que les utilisateurs doivent consulter et avec laquelle ils doivent interagir avant de pouvoir accéder à un réseau public, utilisée pour l'authentification, l'acceptation de la charte d'utilisation et l'initiation de la session.
Le mécanisme principal pour établir l'identité de l'utilisateur et créer une piste d'audit. Sans lui, l'accès anonyme rend le Safe Harbour intenable.
Filtrage DNS
Le processus de blocage de l'accès à certains sites web ou adresses IP en interceptant et en évaluant les requêtes du système de noms de domaine (DNS) par rapport à une base de données de cybermenaces avant de résoudre l'adresse IP.
La méthode la plus efficace et à faible latence pour bloquer le contenu malveillant ou inapproprié à grande échelle. Adaptée aux environnements à haut débit sans nécessiter de matériel DPI.
Piste d'audit
Un enregistrement chronologique et inviolable des événements réseau, comprenant l'authentification de l'utilisateur, les attributions de baux IP, les heures de début/fin de session et l'identité authentifiée.
Requise pour répondre aux demandes des forces de l'ordre, démontrer la conformité réglementaire et prouver que des mesures raisonnables ont été prises pour prévenir les activités illégales.
Inspection approfondie des paquets (DPI)
Filtrage avancé des paquets réseau qui examine la charge utile des données d'un paquet lorsqu'il passe par un point d'inspection, permettant l'identification et le contrôle au niveau de l'application.
Offre le contrôle le plus granulaire mais nécessite une puissance de traitement importante et peut réduire le débit du réseau. À utiliser de préférence de manière sélective pour la détection de protocoles à haut risque.
DNS over HTTPS (DoH)
Un protocole permettant d'effectuer une résolution DNS à distance via le protocole HTTPS, chiffrant la requête DNS pour empêcher l'interception ou la manipulation par les opérateurs de réseau.
Le principal mécanisme de contournement qui compromet le filtrage basé uniquement sur le DNS. Doit être bloqué au niveau du pare-feu en maintenant une liste de blocage des IP de résolveurs DoH connus.
Peer-to-Peer (P2P)
Un modèle de communication décentralisé où chaque nœud participant dispose de capacités équivalentes, couramment utilisé pour le partage de fichiers via des protocoles tels que BitTorrent.
Le principal vecteur de violation des droits d'auteur sur les réseaux publics. Doit être bloqué à la fois au niveau du DNS et de la couche applicative (règles de port/protocole du pare-feu) pour une atténuation efficace.
Randomisation des adresses MAC
Une fonctionnalité de confidentialité dans les systèmes d'exploitation modernes (iOS 14+, Android 10+) qui utilise une adresse MAC aléatoire lors de la connexion aux réseaux WiFi, empêchant le suivi persistant des appareils.
Brise le suivi traditionnel des appareils basé sur l'adresse MAC, obligeant les opérateurs de réseau à s'appuyer sur l'authentification par session via le Captive Portal comme principal identifiant d'audit.
Server Name Indication (SNI)
Une extension du protocole TLS qui permet au client d'indiquer le nom d'hôte auquel il se connecte lors de la phase de handshake TLS, avant que la session chiffrée ne soit établie.
Permet le blocage de contenu par catégorie sur le trafic HTTPS sans déchiffrement complet de la charge utile, offrant un juste milieu entre le filtrage uniquement DNS et le DPI complet.
Exemples concrets
Un hôtel de 200 chambres reçoit des notifications automatisées de violation de droits d'auteur de la part de son FAI parce que des clients téléchargent des films en torrent via le Guest WiFi ouvert. L'hôtel utilise actuellement un réseau WPA2-PSK de base sans Captive Portal ni filtrage de contenu.
Étape 1 : Supprimer la clé PSK partagée et la remplacer par un SSID ouvert précédé d'un Captive Portal. Étape 2 : Exiger que les clients s'authentifient à l'aide de leur numéro de chambre et de leur nom de famille via une intégration PMS, ou via une vérification par SMS/e-mail. Étape 3 : Déployer un service de filtrage DNS basé sur le cloud intégré à la passerelle réseau, en activant les catégories de blocage « P2P/Partage de fichiers » et « Logiciels malveillants ». Étape 4 : Configurer le pare-feu de la passerelle pour bloquer tout le trafic sortant sur les ports BitTorrent standard (6881–6889 TCP/UDP) et bloquer les domaines de trackers de torrent connus via le filtre DNS. Étape 5 : Implémenter des règles NAT pour intercepter tout le trafic du port 53 et le rediriger vers le résolveur DNS géré. Étape 6 : Activer la journalisation des sessions pour capturer l'adresse MAC, l'IP attribuée, l'identité authentifiée et les horodatages de toutes les sessions.
Une grande chaîne de vente au détail déploie un Guest WiFi dans 500 magasins. Elle doit garantir la conformité avec des politiques adaptées aux familles et empêcher la distribution de logiciels malveillants, mais elle ne peut pas se permettre d'installer du matériel DPI à haute latence dans chaque succursale. Elle a également besoin d'une application cohérente des politiques sur tous les sites.
Étape 1 : Déployer une architecture WiFi cloud gérée de manière centralisée avec un contrôleur cloud gérant les points d'accès des 500 succursales. Étape 2 : Implémenter une solution de filtrage DNS basée sur le cloud appliquée au niveau du SSID, configurée de manière centralisée et déployée simultanément sur tous les sites. Étape 3 : Configurer la politique de manière centralisée pour bloquer les catégories « Adulte », « Logiciels malveillants », « Hameçonnage » et « P2P ». Étape 4 : Utiliser le contrôleur cloud pour appliquer des règles NAT redirigeant tout le trafic du port 53 vers le résolveur DNS géré sur chaque site. Étape 5 : Configurer un agrégateur de journaux centralisé pour collecter les journaux de session des 500 sites dans une seule plateforme SIEM ou de gestion des journaux pour les rapports de conformité.
Questions d'entraînement
Q1. Votre établissement met à niveau son Wi-Fi invité. L'architecte réseau propose de supprimer le Captive Portal pour offrir une expérience utilisateur plus fluide, en s'appuyant uniquement sur un filtre DNS cloud pour bloquer les contenus indésirables. Quel est le principal risque juridique de cette approche, et que recommanderiez-vous à la place ?
Conseil : Considérez ce qui se passe si les forces de l'ordre demandent des informations sur une adresse IP spécifique utilisée à un moment précis.
Voir la réponse type
La suppression du Captive Portal élimine la couche d'authentification, ce qui signifie qu'il n'y a pas de piste d'audit reliant une session réseau à l'identité d'un utilisateur spécifique. Bien que le filtre DNS bloque les sites malveillants connus, si un utilisateur le contourne ou commet un acte illégal non détecté par le filtre, l'établissement ne pourra pas identifier l'utilisateur. Cela annule les protections de type "safe harbour", laissant l'établissement entièrement responsable. La recommandation est de conserver le Captive Portal avec authentification obligatoire, et d'utiliser le filtre DNS comme une couche complémentaire — et non comme un substitut à la vérification d'identité.
Q2. Un utilisateur se plaint de ne pas pouvoir accéder à un VPN d'entreprise légitime alors qu'il est connecté à votre Wi-Fi invité filtré. Vous vérifiez les journaux et constatez que la connexion est interrompue au niveau de la passerelle, et non au niveau du DNS. Quelles sont les deux causes les plus probables, et comment résoudriez-vous chacune d'elles ?
Conseil : Pensez à la façon dont les pare-feu gèrent le trafic chiffré et les ports non standard, ainsi qu'au fonctionnement des protocoles VPN.
Voir la réponse type
Cause 1 : Le pare-feu a une politique de sortie trop restrictive qui bloque les ports spécifiques utilisés par le protocole VPN — par exemple, UDP 500 et UDP 4500 pour IKEv2/IPsec, ou TCP/UDP 1194 pour OpenVPN. Résolution : Autoriser les ports VPN standard pour le trafic sortant tout en surveillant les abus. Cause 2 : Un moteur DPI rejette le trafic du tunnel chiffré car il ne peut pas inspecter la charge utile et est configuré pour bloquer les sessions chiffrées non reconnues. Résolution : Créer une exception au niveau de la couche applicative pour les protocoles VPN connus, ou désactiver le DPI pour le trafic sur les ports VPN standard.
Q3. Vous avez déployé une solution robuste de filtrage DNS cloud sur le réseau de votre établissement, mais votre tableau de bord d'analyse Wi-Fi indique une consommation de bande passante importante correspondant à du trafic BitTorrent. Comment cela est-il possible si le filtrage DNS est actif, et quels contrôles supplémentaires devez-vous mettre en œuvre ?
Conseil : Le DNS résout uniquement les noms en adresses IP. Considérez comment les logiciels P2P découvrent et se connectent aux pairs après le contact initial avec le tracker.
Voir la réponse type
BitTorrent et les autres protocoles P2P utilisent le DNS uniquement pour la découverte initiale du tracker. Une fois les pairs découverts, le client s'y connecte directement via l'adresse IP, contournant complètement le DNS. Le filtrage DNS seul ne peut pas arrêter le transfert de données de pair à pair une fois la connexion initiale établie. Pour résoudre ce problème, vous devez configurer le pare-feu de la passerelle réseau pour bloquer les protocoles P2P à l'aide d'un filtrage de la couche applicative ou en bloquant les plages de ports BitTorrent connues (6881–6889 TCP/UDP) et le protocole DHT (UDP 6881). De plus, envisagez d'activer la limitation de la bande passante pour tout trafic P2P résiduel utilisant des ports non standard.
Continuer la lecture de cette série
DNS Over HTTPS (DoH) : implications pour le filtrage du WiFi public
Ce guide de référence technique explique comment le DNS over HTTPS (DoH) contourne le filtrage de contenu traditionnel du port 53 sur les réseaux WiFi publics. Il fournit des stratégies d'atténuation exploitables et neutres vis-à-vis des fournisseurs pour permettre aux architectes réseau et aux responsables informatiques de regagner en visibilité, d'assurer la conformité et de sécuriser l'accès des invités dans les environnements d'entreprise.
Bloquer les logiciels malveillants et le phishing à la périphérie du réseau
Ce guide de référence technique présente l'architecture, le déploiement et l'impact commercial de la mise en œuvre d'une protection contre les menaces au niveau du réseau afin de sécuriser les appareils non gérés des invités et de l'IoT à la périphérie du réseau. Il fournit des conseils pratiques aux responsables informatiques pour bloquer de manière proactive les logiciels malveillants et le phishing.
Conformité IWF pour les réseaux WiFi publics au Royaume-Uni
Ce guide de référence détaille les exigences techniques, l'architecture et les stratégies de déploiement pour la mise en œuvre de réseaux WiFi publics conformes à l'IWF dans les établissements du Royaume-Uni. Il fournit aux responsables informatiques des cadres d'action concrets pour atténuer les risques juridiques tout en maintenant un accès réseau de haute performance.