L'EU AI Act et le Guest WiFi : ce que les marketeurs doivent savoir
L'EU AI Act (règlement 2024/1689) introduit un cadre fondé sur le risque qui affecte directement la façon dont les exploitants de sites déploient le marketing WiFi basé sur l'IA, les Captive Portals et l'analyse des visiteurs. Ce guide associe les quatre niveaux de risque du règlement à des cas d'usage réels du Guest WiFi, identifie les pratiques interdites telles que l'inférence des émotions et le scoring social, et fournit des mesures de conformité concrètes pour les équipes informatiques et les directeurs marketing opérant dans l'hôtellerie, le retail, l'événementiel et le secteur public. Comprendre où se situe votre déploiement sur le spectre des risques — et mettre en œuvre les obligations de transparence de l'article 50 pour les chatbots IA et les portails conversationnels — n'est plus facultatif : l'application des interdictions de pratiques a débuté en février 2025.
Écouter ce guide
Voir la transcription du podcast
- Synthèse de direction
- Analyse technique approfondie
- Le cadre de classification des risques à quatre niveaux
- Prohibited Practices Under Article 5
- Systèmes à haut risque selon l'Annexe III
- Obligations de transparence de l'Article 50 — La priorité immédiate
- L'AI Act et le GDPR : un cadre de conformité superposé
- Guide de mise en œuvre
- Étape 1 : Établir l'inventaire de vos solutions d'IA
- Étape 2 : Classer chaque système selon les niveaux de risque
- Étape 3 : Mettre en œuvre les obligations d'information de l'Article 50
- Étape 4 : Réviser les contrats de sous-traitance des fournisseurs
- Étape 5 : S'aligner sur la gouvernance GDPR
- Étape 6 : Planifier la conformité des systèmes à haut risque (Échéance août 2026)
- Bonnes pratiques
- Dépannage et atténuation des risques
- ROI & Impact Commercial
- Écouter : Podcast sur l'EU AI Act et le WiFi invité

Synthèse de direction
Le Règlement européen sur l'IA (Règlement 2024/1689) est le premier cadre juridique complet au monde régissant l'intelligence artificielle, et il s'applique directement à la manière dont les exploitants de sites déploient l'IA sur l'infrastructure Guest WiFi . Le règlement classe les systèmes d'IA en quatre niveaux de risque — Prohibé, Haut risque, Risque limité et Risque minimal — et attribue des obligations de conformité en conséquence. Pour la plupart des exploitants du secteur de l' hôtellerie et du commerce de détail , l'impact opérationnel immédiat concerne deux domaines : premièrement, s'assurer que toute interface conversationnelle pilotée par l'IA sur un Captive Portal comporte une déclaration de transparence claire au titre de l'article 50 ; et deuxièmement, auditer les outils marketing existants pour confirmer qu'ils n'utilisent pas de pratiques interdites telles que l'inférence des émotions, le scoring social ou la catégorisation biométrique basée sur des attributs sensibles.
Les dispositions relatives aux pratiques interdites au titre de l'article 5 sont devenues exécutoires en février 2025. Les obligations relatives aux systèmes à haut risque au titre de l'annexe III s'appliquent à partir d'août 2026. Les amendes pour violation des pratiques interdites peuvent atteindre jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial. Ce guide fournit une référence technique pour les directeurs informatiques, les architectes réseau et les responsables de la conformité qui doivent évaluer leurs déploiements actuels et mettre en œuvre les changements requis ce trimestre.
Analyse technique approfondie
Le cadre de classification des risques à quatre niveaux
Le Règlement européen sur l'IA classe les systèmes d'IA selon le risque qu'ils posent pour les droits fondamentaux, la sécurité et les valeurs démocratiques. La classification détermine les obligations de conformité qui s'appliquent à la fois au fournisseur (le développeur ou le vendeur du système d'IA) et au déployeur (l'organisation qui met le système en service — généralement l'exploitant du site ou l'équipe informatique).

Les quatre niveaux, appliqués aux contextes du Guest WiFi et du marketing sur site, sont les suivants :
| Niveau de risque | Référence du Règlement sur l'IA | Exemples de Marketing WiFi | Obligation de conformité |
|---|---|---|---|
| Prohibé | Article 5 | Inférence des émotions lors des interactions sur le portail ; scoring social des clients ; catégorisation biométrique par race/religion | Cessation immédiate ; aucun déploiement autorisé |
| Haut risque | Annexe III | Vérification biométrique sur le Captive Portal ; profilage par IA pour l'accès aux services essentiels | Évaluation de la conformité, documentation technique, système de gestion des risques, enregistrement dans la base de données de l'UE |
| Risque limité | Article 50 | Chatbots IA sur les Captive Portals ; pages d'accueil (splash pages) générées par IA ; systèmes de reconnaissance des émotions (contextes non prohibés) | Déclaration de transparence aux utilisateurs finaux avant/pendant l'interaction |
| Minimal Risk | No specific obligation | Aggregate footfall analytics; dwell-time heatmaps; rules-based personalisation; bandwidth optimisation AI | No AI Act-specific obligations (GDPR still applies) |
Prohibited Practices Under Article 5
Article 5 of the AI Act defines eight categories of prohibited AI practice. Three are directly relevant to venue WiFi marketing deployments.
Manipulative and Deceptive Techniques. The Act prohibits AI systems that deploy subliminal, manipulative, or deceptive techniques to distort a person's behaviour and impair their ability to make an informed decision, where this causes or is likely to cause significant harm. In a WiFi marketing context, this targets systems that exploit behavioural signals captured at the Captive Portal — click hesitation, scroll patterns, time-on-page — to infer psychological vulnerabilities and serve manipulative offers. The key threshold is significant harm; regulators will assess this contextually, but the principle is clear: AI-driven nudging that bypasses rational agency is out of scope.
Social Scoring. The Act prohibits AI systems that evaluate or classify individuals based on their social behaviour or personal characteristics, where this leads to detrimental or unfavourable treatment. A WiFi loyalty system that uses an AI model to score guests on behavioural patterns — visit frequency, dwell time, purchase signals — and then restricts access speed or withholds offers from lower-scoring guests would fall within this prohibition. The distinction between permissible personalisation and prohibited social scoring lies in whether the AI classification produces detrimental treatment: serving a premium guest a better offer is personalisation; denying a lower-scoring guest access to services is social scoring.
Biometric Categorisation of Sensitive Attributes. The Act prohibits AI systems that use biometric data to infer sensitive attributes including race, political opinion, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation. This is particularly relevant for venues using camera-based analytics alongside WiFi data. If an AI system cross-references device MAC address data with visual analytics to infer ethnicity and personalise content accordingly, that is a direct Article 5 violation. The prohibition applies regardless of whether the biometric data is processed in real time or in batch.
Inférence des émotions — Clarification du champ d'application. L'Acte interdit l'inférence des émotions sur les lieux de travail et dans les établissements d'enseignement. Cette interdiction ne s'étend pas automatiquement aux espaces de vente, aux hôtels ou aux stades concernant les visiteurs. Cependant, si votre établissement est également un lieu de travail — un campus d'entreprise, un espace de co-working, un hôpital — et que vous utilisez l'inférence des émotions sur des employés connectés au WiFi visiteur, cela est interdit. Les exploitants de sites doivent cartographier soigneusement leurs populations d'utilisateurs avant de supposer que l'interdiction de l'inférence des émotions ne s'applique pas.
Systèmes à haut risque selon l'Annexe III
L'Annexe III de l'Acte énumère les cas d'usage classés comme à haut risque. Pour les déploiements de WiFi invités, deux catégories sont directement concernées.
Premièrement, les systèmes biométriques : les systèmes d'identification biométrique à distance (à l'exclusion de la simple vérification biométrique qui confirme qu'une personne est bien celle qu'elle prétend être) et les systèmes de catégorisation biométrique déduisant des attributs sensibles ou protégés sont considérés comme à haut risque. Si votre Captive Portal utilise la reconnaissance faciale pour authentifier les visiteurs de retour, ce système nécessite une évaluation complète de la conformité, une documentation technique, un système de gestion des risques tout au long du cycle de vie du système, et un enregistrement dans la base de données de l'UE sur l'IA Act.
Deuxièmement, le profilage individuel : tout système d'IA répertorié sous l'Annexe III est toujours considéré comme à haut risque s'il profile des individus — défini comme le traitement automatisé de données personnelles pour évaluer des aspects de la vie d'une personne, y compris ses préférences, ses intérêts, son comportement, et sa localisation ou ses déplacements. Il s'agit de la disposition la plus susceptible de concerner les plateformes de WiFi Analytics qui créent des profils individuels persistants alimentant des décisions marketing automatisées. La question clé est de savoir si le système d'IA prend ou influence substantiellement des décisions automatisées concernant des visiteurs individuels en fonction de leurs caractéristiques profilées.
Obligations de transparence de l'Article 50 — La priorité immédiate
Pour la majorité des exploitants de sites aujourd'hui, l'Article 50 est la disposition la plus pertinente sur le plan opérationnel. Elle couvre trois scénarios :
Systèmes d'IA conversationnels (Article 50(1)) : Les fournisseurs doivent s'assurer que les systèmes d'IA destinés à interagir avec des personnes physiques sont conçus de manière à ce que ces personnes soient informées qu'elles interagissent avec un système d'IA, à moins que cela ne soit évident d'après le contexte. Les déployeurs doivent veiller à ce que cette information soit en place. Cela s'applique à tout chatbot d'IA déployé sur un Captive Portal — que ce soit pour les services aux visiteurs, l'aide à l'enregistrement à l'hôtel, la navigation dans l'établissement ou les questions marketing.
Reconnaissance des émotions et catégorisation biométrique (Article 50(3)) : Les déployeurs de systèmes de reconnaissance des émotions ou de systèmes de catégorisation biométrique doivent informer les personnes physiques exposées à ces systèmes. Il s'agit d'une obligation distincte de l'information relative aux chatbots, qui s'applique même lorsque le système n'est pas interdit.
Contenu synthétique (Article 50(4)) : les systèmes d'IA générant du contenu audio, image, vidéo ou textuel synthétique doivent marquer ce contenu comme étant généré par IA. Si votre Captive Portal utilise l'IA générative pour produire des messages de bienvenue personnalisés ou des textes promotionnels, ce contenu doit être étiqueté.

L'AI Act et le GDPR : un cadre de conformité superposé
L'AI Act ne remplace pas le GDPR ; il fonctionne en parallèle. Pour les exploitants de sites, cela signifie que les obligations de conformité des deux cadres s'appliquent simultanément aux déploiements de marketing WiFi basés sur l'IA.
Sous le GDPR, les dispositions pertinentes pour le marketing WiFi basé sur l'IA comprennent : l'Article 6 (base légale du traitement), l'Article 9 (données de catégorie particulière — pertinent si des données biométriques sont traitées), l'Article 13/14 (obligations de transparence dans les avis de confidentialité), l'Article 22 (restrictions sur la prise de décision individuelle automatisée) et l'Article 35 (analyse d'impact relative à la protection des données pour les traitements à haut risque).
L'AI Act ajoute : l'Article 5 (conformité aux pratiques interdites), l'Article 50 (divulgation de transparence au point d'interaction avec l'IA) et — pour les systèmes à haut risque — les Articles 8 à 17 (gestion des risques, documentation technique, évaluation de la conformité, enregistrement).
Là où le GDPR exige une analyse d'impact (DPIA) pour le traitement des données à haut risque, l'AI Act exige un système de gestion des risques pour les systèmes d'IA à haut risque. Ceux-ci peuvent et doivent être alignés : une évaluation intégrée unique couvrant à la fois les risques liés au traitement des données (GDPR) et les risques liés au système d'IA (AI Act) est plus efficace et démontre une posture de gouvernance mature face aux régulateurs.
L'Article 22 du GDPR est particulièrement pertinent pour les portails captifs pilotés par l'IA. Il restreint les décisions exclusivement automatisées qui produisent des effets juridiques ou affectent de manière tout aussi significative les individus. Si votre système d'IA prend des décisions automatisées concernant les niveaux d'accès WiFi, l'éligibilité aux promotions ou la qualité du service sans intervention humaine, vous devez évaluer si l'Article 22 s'applique et si vous devez offrir aux clients le droit de demander un examen humain.
Guide de mise en œuvre
Étape 1 : Établir l'inventaire de vos solutions d'IA
Avant de pouvoir évaluer la conformité, vous devez avoir une vue d'ensemble de chaque système d'IA présent dans votre pile marketing WiFi. Cela implique d'aller au-delà de vos propres déploiements pour inclure les composants d'IA intégrés dans des plateformes tierces — outils d'automatisation marketing, tableaux de bord analytiques, fournisseurs de Captive Portal et intégrations CRM.
Pour chaque système, documentez : la fonction du système, les données qu'il traite, le fournisseur et les éventuels sous-traitants ultérieurs, le niveau de risque selon l'AI Act et les obligations de conformité applicables. Cet inventaire constitue le fondement de votre posture de conformité à l'AI Act et sera exigé si les régulateurs demandent des preuves de diligence raisonnable.
Étape 2 : Classer chaque système selon les niveaux de risque
Appliquez le cadre à quatre niveaux à chaque système de votre inventaire. Les questions de classification sont les suivantes :
- Le système utilise-t-il une pratique répertoriée à l'Article 5 ? Si oui, il est interdit — cessez le déploiement.
- Le système est-il utilisé pour la vérification biométrique, le profilage individuel pour l'accès aux services, ou tout autre cas d'usage de l'Annexe III ? Si oui, il est à haut risque — commencez la planification de l'évaluation de la conformité.
- Le système interagit-il de manière conversationnelle avec des personnes physiques, génère-t-il du contenu synthétique ou effectue-t-il de la reconnaissance des émotions ? Si oui, il est à risque limité — mettez en œuvre les obligations d'information de l'Article 50.
- Rien de tout cela ? Il est à risque minimal — aucune obligation spécifique à l'AI Act, mais la conformité au GDPR reste obligatoire.
Étape 3 : Mettre en œuvre les obligations d'information de l'Article 50
Pour tout chatbot IA ou interface conversationnelle sur votre Captive Portal, mettez en œuvre une information claire avant le début de l'interaction. Cette information doit être explicite — non implicite, non dissimulée dans les conditions générales. Un simple élément d'interface utilisateur indiquant "Vous discutez avec un assistant IA" au début de la session suffit à remplir cette obligation. Il s'agit d'une modification front-end, et non d'une reconstruction du système, qui devrait pouvoir être déployée en un seul sprint.
Pour les systèmes de reconnaissance des émotions fonctionnant dans votre établissement (lorsqu'ils ne sont pas interdits), ajoutez un avis visible dans la zone d'exploitation informant les visiteurs qu'un système de reconnaissance des émotions est utilisé.
Étape 4 : Réviser les contrats de sous-traitance des fournisseurs
En tant que déployeur, vous partagez la responsabilité des pratiques interdites utilisées par vos fournisseurs. Examinez vos contrats avec les fournisseurs de plateformes de marketing WiFi, les prestataires d'analyses et les fournisseurs de Captive Portal. Demandez une confirmation explicite de leur classification au titre de l'AI Act et leur documentation de conformité. Ajoutez des dispositions contractuelles exigeant que les fournisseurs vous informent de toute modification apportée à leurs systèmes d'IA susceptible d'affecter la classification des risques.
Étape 5 : S'aligner sur la gouvernance GDPR
Associez votre délégué à la protection des données au processus de conformité à l'AI Act. Mettez à jour votre registre des activités de traitement pour y inclure les classifications des systèmes d'IA. Lorsqu'une analyse d'impact relative à la protection des données (DPIA) est requise par le GDPR pour les traitements de données à haut risque, étendez-la pour couvrir les exigences de gestion des risques de l'AI Act. Assurez-vous que vos mentions de confidentialité sont mises à jour pour refléter les traitements basés sur l'IA et les informations requises par l'Article 50.
Étape 6 : Planifier la conformité des systèmes à haut risque (Échéance août 2026)
Si l'un de vos systèmes est classé comme étant à haut risque, commencez le processus d'évaluation de la conformité dès maintenant. L'échéance d'août 2026 pour les systèmes de l'Annexe III est plus proche qu'elle n'y paraît si l'on prend en compte le temps nécessaire à la documentation technique, à la mise en œuvre du système de gestion des risques et à l'enregistrement dans la base de données de l'UE. Sollicitez vos fournisseurs dès à présent pour savoir quelle documentation ils peuvent fournir et ce que vous devez produire en tant que déployeur.
Bonnes pratiques
Adoptez une approche de « Privacy-by-Design » pour le déploiement de l'IA. Les exigences de l'IA Act pour les systèmes à haut risque — gestion des risques tout au long du cycle de vie, gouvernance des données, documentation technique — sont satisfaites de la manière la plus efficace lorsqu'elles sont intégrées à l'architecture du système dès le départ plutôt que d'être adaptées a posteriori. Lors de l'évaluation de nouveaux outils marketing basés sur l'IA, incluez les exigences de conformité à l'IA Act dans vos critères d'achat, aux côtés de la conformité au GDPR et des normes de sécurité telles que ISO 27001 et PCI DSS.
Privilégiez les données de première partie basées sur le consentement plutôt que les attributs déduits. Les pratiques interdites et les classifications à haut risque de l'IA Act visent principalement les systèmes d'IA qui déduisent des caractéristiques sensibles ou prennent des décisions automatisées importantes concernant les individus. Les systèmes qui utilisent des données de première partie explicitement consenties — adresses e-mail, préférences déclarées, adhésion à un programme de fidélité — pour assurer la personnalisation présentent un risque réglementaire considérablement plus faible que les systèmes qui déduisent des caractéristiques à partir de signaux comportementaux.
Maintenez une séparation entre l'IA de gestion du réseau et l'IA marketing. Les systèmes d'IA utilisés pour la gestion du réseau — allocation de bande passante, atténuation des interférences, équilibrage de charge — présentent un risque minimal en vertu de l'IA Act. Les systèmes d'IA utilisés pour le profilage des invités et la personnalisation marketing comportent un risque plus élevé. Maintenir ces systèmes séparés sur le plan de l'architecture simplifie votre classification des risques et limite l'impact de tout problème de conformité dans l'écosystème marketing.
Référez-vous aux normes IEEE 802.1X et WPA3 pour l'architecture d'authentification. Lorsque la vérification biométrique est utilisée sur le Captive Portal, assurez-vous que l'architecture d'authentification sous-jacente respecte les normes actuelles. La norme IEEE 802.1X fournit un contrôle d'accès réseau basé sur les ports avec une authentification forte, et la norme WPA3 offre un chiffrement amélioré pour la couche sans fil. Ces normes sont indépendantes des fournisseurs et sont référencées à la fois dans les cadres de sécurité d'entreprise et dans les directives du GDPR relatives aux mesures techniques appropriées.
Documentez vos décisions de conformité à l'IA Act. Même pour les systèmes à risque minimal, documenter votre raisonnement de classification démontre votre diligence raisonnable auprès des régulateurs. L'IA Act exige des fournisseurs de systèmes à haut risque qu'ils documentent leur évaluation avant de mettre le système sur le marché ; en tant que déployeur, conserver une documentation équivalente pour vos propres évaluations des risques constitue une bonne pratique.
Dépannage et atténuation des risques
Risque : Les pratiques d'IA des fournisseurs sont opaques. De nombreuses plateformes d'automatisation marketing et d'analyse WiFi intègrent des fonctionnalités d'IA qui ne sont pas clairement documentées. Atténuation : Envoyez un questionnaire formel de conformité à l'IA Act à tous les fournisseurs. Demandez-leur la classification de leur système, leur documentation technique et la preuve qu'ils évitent les pratiques interdites. Incluez la conformité à l'IA Act comme une exigence contractuelle dans les nouveaux contrats et les renouvellements. Risque : Le chatbot du Captive Portal ne respecte pas l'obligation de divulgation de l'Article 50. Il s'agit de la faille de conformité la plus courante identifiée dans les déploiements actuels. Atténuation : Auditez l'interface utilisateur de votre Captive Portal. Si une interface d'IA conversationnelle ne présente pas de divulgation claire avant l'interaction, il s'agit d'une mesure corrective prioritaire. La correction est une simple modification de l'interface utilisateur, déployable en quelques jours.
Risque : La plateforme d'analytics crée des profils individuels qui déclenchent une classification à haut risque. Si votre plateforme WiFi Analytics crée des profils individuels persistants alimentant des décisions marketing automatisées, vous utilisez peut-être un système à haut risque sans l'évaluation de conformité requise. Atténuation : Examinez le modèle de données de la plateforme. Si des profils individuels sont créés et utilisés pour des décisions automatisées, interrogez votre fournisseur sur sa classification au regard de l'AI Act et lancez un processus d'évaluation de la conformité.
Risque : La conformité au GDPR et à l'AI Act est traitée comme des chantiers distincts. Les organisations qui gèrent la conformité au GDPR et à l'AI Act au sein d'équipes distinctes s'exposent à des doublons, des lacunes et une documentation incohérente. Atténuation : Établissez un cadre de gouvernance de l'IA unifié qui traite les deux cadres réglementaires. Un processus unique et intégré d'analyse d'impact relative à la protection des données (DPIA) et d'évaluation des risques liés à l'IA est plus efficace et plus robuste juridiquement.
Risque : Erreur de classification de la portée de l'inférence des émotions. L'interdiction de l'inférence des émotions s'applique aux lieux de travail et aux établissements d'enseignement. Les établissements qui sont également des lieux de travail (campus d'entreprises, hôpitaux, espaces de coworking) doivent appliquer cette interdiction aux systèmes destinés aux employés, et pas seulement à ceux destinés aux clients. Atténuation : Cartographiez vos populations d'utilisateurs et appliquez l'interdiction à tous les contextes où les employés pourraient faire l'objet d'une inférence des émotions.
ROI & Impact Commercial
La conformité à l'EU AI Act n'est pas uniquement un centre de coûts. Les organisations qui développent des cadres de gouvernance de l'IA en amont de la courbe d'application de la loi en retirent des avantages concurrentiels mesurables.
Réduction du risque réglementaire. Les amendes pour violation des pratiques interdites (jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial) représentent un risque financier matériel pour toute entreprise opérant à grande échelle dans les États membres de l'UE. Une posture de conformité proactive élimine cette exposition.
Différenciation des fournisseurs. Alors que la conformité à l'AI Act devient une exigence d'achat, les plateformes capables de démontrer une classification claire des risques, des pratiques d'IA transparentes et des interfaces conformes à l'Article 50 seront privilégiées. Pour les exploitants du secteur de l' hôtellerie et du commerce de détail qui évaluent les plateformes de marketing WiFi, la documentation de conformité à l'AI Act devient une exigence standard des appels d'offres.
Confiance des clients et qualité des données de première main. Les obligations de transparence découlant de l'article 50 — lorsqu'elles sont bien appliquées — renforcent la confiance des clients. Les clients qui comprennent comment l'IA est utilisée dans leur interaction sont plus susceptibles de s'engager de manière authentique et de fournir des données de première main de meilleure qualité. Cela améliore directement la précision des modèles de personnalisation et le ROI des campagnes marketing.
Efficacité opérationnelle grâce à une gouvernance unifiée. Les organisations qui alignent leurs cadres de conformité GDPR et AI Act au sein d'une structure de gouvernance unique réduisent les doublons d'efforts entre les équipes juridiques, informatiques et marketing. L'investissement dans la mise en place de ce cadre porte ses fruits à mesure que le paysage réglementaire continue d'évoluer — l'AI Act sera suivi d'autres réglementations spécifiques à l'IA, et une posture de gouvernance mature constitue un socle durable.
Pour les opérateurs de transport et les organisations du secteur public, la conformité à l'AI Act est particulièrement cruciale compte tenu de la surveillance accrue des systèmes d'IA dans les espaces accessibles au public. Une conformité proactive démontre une responsabilité tant envers les régulateurs qu'envers le public, soutenant ainsi des objectifs plus larges de confiance numérique.
Pour aller plus loin sur les cadres de conformité associés, consultez notre guide sur la Conformité PIPEDA pour le WiFi invité au Canada , qui couvre les exigences analogues de consentement et de transparence dans le contexte canadien.
Écouter : Podcast sur l'EU AI Act et le WiFi invité
Définitions clés
Fournisseur (EU AI Act)
Toute personne physique ou morale, autorité publique, agence ou autre organisme qui développe un système d'IA ou un modèle d'IA à usage général, ou qui fait développer un système d'IA ou un modèle d'IA à usage général, en vue de le mettre sur le marché ou de le mettre en service sous son propre nom ou sa propre marque, à titre onéreux ou gratuit.
Dans le contexte du WiFi Invité, le fournisseur est généralement l'éditeur de la plateforme marketing WiFi ou le développeur du moteur de personnalisation IA. Les fournisseurs de systèmes à haut risque portent les obligations de conformité les plus lourdes en vertu de la loi.
Déployeur (EU AI Act)
Toute personne physique ou morale, autorité publique, agence ou autre organisme qui utilise un système d'IA sous sa propre autorité, sauf lorsque le système d'IA est utilisé dans le cadre d'une activité personnelle non professionnelle.
L'exploitant du site — groupe hôtelier, chaîne de magasins, exploitant de stade — est le déployeur. Les déployeurs sont responsables des obligations de transparence de l'Article 50 et doivent s'assurer que les systèmes d'IA qu'ils utilisent respectent les exigences de la loi, même lorsque ces systèmes sont fournis par des tiers.
Système de catégorisation biométrique
Un système d'IA destiné à attribuer des personnes physiques à des catégories spécifiques sur la base de leurs données biométriques, telles que le visage, le mouvement, la démarche, la posture, la voix, l'apparence, le comportement ou d'autres caractéristiques ou traits physiques ou comportementaux humains.
Pertinent pour les exploitants de sites utilisant des analyses basées sur des caméras ou l'empreinte numérique des appareils en combinaison avec l'IA. Les systèmes qui déduisent des attributs sensibles (race, religion, opinion politique) à partir de données biométriques sont interdits en vertu de l'Article 5. Les systèmes qui effectuent une catégorisation biométrique sans déduire d'attributs sensibles peuvent être classés comme à haut risque selon l'Annexe III.
Système de reconnaissance des émotions
Un système d'IA destiné à identifier ou à déduire les émotions ou les intentions de personnes physiques sur la base de leurs données biométriques.
Interdit sur les lieux de travail et dans les établissements d'enseignement en vertu de l'Article 5. Dans d'autres contextes de sites (commerce de détail, hôtellerie), les systèmes de reconnaissance des émotions sont réglementés par l'Annexe III comme étant à haut risque et exigent que les déployeurs informent les personnes concernées conformément à l'Article 50(3). Les éditeurs commercialisant des fonctionnalités basées sur "l'humeur" ou "l'état d'engagement" doivent être évalués par rapport à cette définition.
Profilage individuel
Toute forme de traitement automatisé de données à caractère personnel consistant à utiliser ces données pour évaluer certains aspects personnels relatifs à une personne physique, notamment pour analyser ou prédire des éléments concernant ses performances, sa situation économique, sa santé, ses préférences personnelles, ses intérêts, sa fiabilité, son comportement, sa localisation ou ses déplacements.
Les systèmes d'IA répertoriés dans l'Annexe III sont toujours considérés comme à haut risque s'ils profilent des individus. Les plateformes d'analyse WiFi qui créent des profils individuels persistants alimentant des décisions marketing automatisées doivent être évaluées par rapport à cette définition afin de déterminer s'il s'agit de systèmes à haut risque.
Notation sociale
L'évaluation ou la classification de personnes physiques ou de groupes de personnes sur une période donnée, sur la base de leur comportement social ou de caractéristiques personnelles ou de personnalité connues, déduites ou prédites, cette notation sociale entraînant un traitement préjudiciable ou défavorable de ces personnes ou groupes dans des contextes sociaux sans rapport avec ceux dans lesquels les données ont été initialement générées ou collectées.
Interdite en vertu de l'Article 5. Dans un contexte de marketing WiFi, cela vise les systèmes d'IA qui évaluent les invités en fonction de leurs comportements et utilisent ces notes pour restreindre l'accès, retenir des offres ou fournir un service de moindre qualité. L'élément clé est le traitement préjudiciable : une personnalisation qui améliore l'expérience des invités à forte valeur ajoutée ne constitue pas une notation sociale, à moins qu'elle ne désavantage simultanément les invités ayant obtenu des notes inférieures.
Captive Portal
Une page web ou une passerelle d'authentification présentée aux utilisateurs nouvellement connectés à un réseau WiFi avant qu'un accès plus large à Internet ne leur soit accordé. Utilisé par les exploitants de sites pour collecter les données des invités, présenter les conditions de service et diffuser du contenu marketing.
La principale surface de déploiement pour le marketing WiFi optimisé par l'IA. Les fonctionnalités d'IA sur les portails captifs — chatbots, pages d'accueil personnalisées, moteurs de recommandation — sont soumises aux obligations de transparence de l'Article 50. Le Captive Portal est également le point de contact où le consentement GDPR pour le traitement des données est généralement obtenu.
Évaluation de la conformité
Le processus de vérification de la conformité d'un système d'IA à haut risque avec les exigences définies par l'EU AI Act, comprenant la gestion des risques, la gouvernance des données, la documentation technique, la transparence, la surveillance humaine, l'exactitude, la robustesse et la cybersécurité.
Requise pour les systèmes d'IA à haut risque avant leur mise sur le marché ou leur mise en service. Pour la plupart des systèmes à haut risque de l'Annexe III, les fournisseurs peuvent effectuer une auto-évaluation. Pour les systèmes d'identification biométrique, une évaluation par un tiers est requise. Les exploitants de sites déployant des systèmes d'IA à haut risque doivent s'assurer que leurs fournisseurs ont réalisé l'évaluation de conformité requise et peuvent fournir la documentation nécessaire.
AIPD (Analyse d'Impact relative à la Protection des Données)
Un processus requis par l'Article 35 du GDPR pour les opérations de traitement susceptibles d'engendrer un risque élevé pour les droits et libertés des personnes physiques. L'AIPD doit décrire le traitement, évaluer la nécessité et la proportionnalité, ainsi qu'identifier et atténuer les risques.
Requise par le GDPR pour les traitements de données à haut risque, y compris le profilage à grande échelle et la surveillance systématique des zones accessibles au public. Dans le contexte de l'AI Act, l'AIPD devrait être étendue pour couvrir les exigences de gestion des risques des systèmes d'IA, créant ainsi une évaluation unifiée qui satisfait aux deux cadres réglementaires.
Obligation de transparence de l'Article 50
L'exigence formulée à l'Article 50 de l'EU AI Act selon laquelle les fournisseurs doivent s'assurer que les systèmes d'IA destinés à interagir avec des personnes physiques sont conçus de manière à ce que ces personnes soient informées qu'elles interagissent avec un système d'IA, sauf si cela ressort clairement du contexte. Les déployeurs doivent veiller à ce que cette information soit bien mise en place.
L'obligation de conformité la plus immédiatement exploitable pour les exploitants de sites proposant des chatbots IA ou des interfaces conversationnelles sur leurs portails captifs. L'information doit être claire et préalable — avant le début de l'interaction — et non dissimulée dans les conditions générales. S'applique à tous les systèmes conversationnels d'IA, quel que soit leur niveau de risque.
Exemples concrets
A 450-room hotel group operating across five EU member states has deployed an AI-driven chatbot on its captive portal to handle guest check-in queries, restaurant recommendations, and WiFi troubleshooting. The chatbot is powered by a third-party LLM platform. The marketing team also uses a WiFi analytics platform that builds individual guest profiles — including visit history, dwell time by venue area, and inferred demographic segments — to serve personalised promotional offers via the captive portal splash page. The CTO needs to assess the AI Act compliance posture of both systems before the next board meeting.
Étape 1 — Classifier le chatbot. Le chatbot piloté par IA est un système d'IA conversationnel interagissant avec des personnes physiques. Il relève de l'article 50(1) en tant que système à risque limité. L'action immédiate consiste à implémenter une mention d'information claire avant l'interaction sur l'interface utilisateur du Captive Portal : « Vous discutez avec un assistant IA. » Il s'agit d'une modification d'interface utilisateur (front-end). Le groupe hôtelier, en tant que déployeur, est responsable de cette divulgation même si le LLM sous-jacent est fourni par un tiers. Examinez le contrat du fournisseur pour confirmer la classification du système au regard de l'AI Act et demandez sa documentation technique.
Étape 2 — Classifier la plateforme d'analyse. La plateforme d'analyse WiFi crée des profils d'invités individuels et les utilise pour proposer des offres personnalisées via des décisions automatisées. La question clé est de savoir si cela constitue un profilage individuel au sens de l'annexe III (traitement automatisé de données à caractère personnel pour évaluer les préférences, les intérêts, le comportement et la localisation). Si oui, le système est à haut risque. Demandez la documentation de classification AI Act du fournisseur. Si le fournisseur classifie le système en risque minimal, obtenez sa justification écrite et évaluez si elle est défendable. Si le système est à haut risque, commencez à planifier la conformité de l'évaluation de la conformité avant la date limite d'août 2026.
Étape 3 — Auditer les segments démographiques déduits. Si la plateforme d'analyse déduit des segments démographiques incluant des attributs sensibles (tranche d'âge, sexe, nationalité) à l'aide de modèles d'IA, évaluez si cela constitue une catégorisation biométrique d'attributs sensibles au titre de l'article 5. Si la segmentation est basée sur des données déclarées (adhésion à un programme de fidélité, préférences explicitement fournies) plutôt que sur une déduction par IA à partir de signaux comportementaux, le risque est plus faible. S'il s'agit d'une déduction par IA à partir de signaux comportementaux, cela nécessite un examen juridique approfondi.
Étape 4 — Aligner avec le GDPR. Assurez-vous que la politique de confidentialité du groupe hôtelier reflète le traitement basé sur l'IA et les divulgations de l'article 50. Examinez la base légale du traitement analytique en vertu de l'article 6 du GDPR. Si le traitement est basé sur des intérêts légitimes, menez une évaluation des intérêts légitimes qui prend en compte la classification des risques de l'AI Act. Mettez à jour la DPIA pour couvrir à la fois les dimensions de risque du GDPR et de l'AI Act.
A national retail chain with 120 stores across Germany, France, and the Netherlands is evaluating a new WiFi marketing platform that includes an AI feature described by the vendor as 'mood-based personalisation' — the system analyses the speed and pattern of a guest's captive portal interactions to infer their 'engagement state' and adjusts the promotional content served on the splash page accordingly. The IT director needs to assess whether this feature is permissible under the EU AI Act.
Étape 1 — Identifier la pratique d'IA. La fonctionnalité de « personnalisation basée sur l'humeur » analyse les signaux comportementaux (vitesse et modèle d'interaction) pour déduire un « état d'engagement » — ce qui correspond fonctionnellement à un état émotionnel ou psychologique. Il s'agit d'une inférence d'émotions.
Étape 2 — Appliquer le test d'interdiction de l'article 5. L'article 5 interdit l'inférence d'émotions sur le lieu de travail et dans les établissements d'enseignement. Un magasin de vente au détail n'est pas un lieu de travail pour le client, cette interdiction spécifique ne s'applique donc pas à la population des clients dans le contexte du commerce de détail. Cependant, la fonctionnalité peut toujours être interdite en vertu de l'article 5(1)(a) si elle déploie des techniques manipulatoires pour altérer le comportement et nuire à la prise de décision éclairée, causant ainsi un préjudice important. L'utilisation d'un état émotionnel déduit pour diffuser du contenu promotionnel manipulatoire — par exemple, cibler un client identifié comme « frustré » avec une offre basée sur l'urgence — est susceptible de tomber sous le coup de cette interdiction.
Étape 3 — Évaluer les implications au regard du GDPR. Déduire un état émotionnel à partir de données comportementales constitue un traitement de données à caractère personnel à des fins de profilage au sens du GDPR. La base légale de ce traitement doit être évaluée. Il est peu probable que l'intérêt légitime soit une base défendable pour l'inférence d'émotions utilisée à des fins de marketing. Le consentement explicite est la base la plus appropriée, mais le mécanisme de consentement doit être spécifique et granulaire — le consentement à l'accès WiFi ne constitue pas un consentement à l'inférence d'émotions.
Étape 4 — Recommandation. Ne déployez pas la fonctionnalité de « personnalisation basée sur l'humeur » sans une évaluation juridique détaillée. Le risque de violation de l'article 5 — spécifiquement l'interdiction de manipulation — est réel. Demandez l'analyse juridique du fournisseur concernant la classification de la fonctionnalité au regard de l'AI Act. Si le fournisseur ne peut pas fournir de classification défendable, considérez la fonctionnalité comme interdite et ne l'activez pas. La personnalisation comportementale standard basée sur des mesures objectives (fréquence des visites, heure de la journée, préférences déclarées) est autorisée et présente un risque réglementaire considérablement plus faible.
Questions d'entraînement
Q1. Le fournisseur de la plateforme de marketing WiFi de votre établissement vient de lancer une nouvelle fonctionnalité appelée "Visitor Sentiment Scoring" qui analyse la vitesse, la séquence et les motifs d'hésitation des interactions d'un visiteur avec le Captive Portal afin de lui attribuer un score de sentiment (positif, neutre, frustré) et d'ajuster le contenu promotionnel proposé en conséquence. La documentation du fournisseur décrit cela comme de l'"analyse comportementale" plutôt que de la "reconnaissance des émotions". En tant que directeur informatique, comment évaluez-vous la conformité de cette fonctionnalité avec l'IA Act de l'UE, et quelles mesures prenez-vous ?
Conseil : Concentrez-vous sur la fonction technique du système, et non sur le discours marketing du fournisseur. Demandez-vous : que fait réellement le système ? Déduit-il un état émotionnel ou psychologique à partir de signaux comportementaux ? Appliquez ensuite le test d'interdiction de l'Article 5 et le test de transparence de l'Article 50.
Voir la réponse type
La fonctionnalité est techniquement un système de reconnaissance des émotions, quelle que soit la dénomination du fournisseur. Analyser des schémas d'interaction pour en déduire de la "frustration" ou un "sentiment positif" relève de l'inférence d'émotions. La première étape consiste à appliquer le test d'interdiction de l'Article 5 : ce système est-il utilisé sur un lieu de travail ou dans un établissement d'enseignement ? Si l'établissement est un magasin de détail ou un hôtel, l'interdiction de l'Article 5 sur le lieu de travail ne s'applique pas aux clients. Cependant, l'interdiction de manipulation au titre de l'Article 5(1)(a) peut s'appliquer si le système utilise le sentiment déduit pour diffuser un contenu manipulateur — par exemple, cibler un client "frustré" avec une offre basée sur l'urgence. La deuxième étape consiste à évaluer si le système relève de l'Annexe III en tant que système de reconnaissance des émotions, ce qui le rendrait à haut risque. La troisième étape consiste à demander au fournisseur sa classification écrite au titre de l'IA Act et son analyse juridique. Si le fournisseur ne peut pas fournir une classification justifiable, n'activez pas la fonctionnalité. Documentez les motifs de votre évaluation quel que soit le résultat.
Q2. Un exploitant de stade gérant une enceinte de 60 000 places utilise la plateforme Guest WiFi de Purple pour collecter des données de première partie lors des événements. L'équipe marketing souhaite déployer un chatbot IA sur le Captive Portal pour répondre aux questions des fans sur les infrastructures, les produits dérivés et les événements à venir. Le chatbot est alimenté par l'API d'un LLM tiers. L'équipe juridique du stade demande : quelles sont les obligations de l'Article 50, qui est responsable de la conformité et à quoi ressemble l'implémentation en pratique ?
Conseil : Identifiez le déployeur, le fournisseur et le scénario applicable de l'Article 50. Précisez ensuite à quoi doit ressembler l'information et quand elle doit apparaître.
Voir la réponse type
L'exploitant du stade est le déployeur ; le fournisseur de l'API LLM est le fournisseur. En vertu de l'Article 50(1), le déployeur est responsable de veiller à ce que les clients soient informés qu'ils interagissent avec un système d'IA avant que l'interaction ne commence. L'implémentation nécessite une mention claire sur l'interface utilisateur du Captive Portal — un badge ou un message d'introduction tel que "Vous discutez avec un assistant IA" — affiché avant l'envoi du premier message. Il s'agit d'une modification front-end du modèle de Captive Portal. L'information doit être explicite et préalable ; elle ne peut pas être enfouie dans les conditions d'utilisation. Le fournisseur de LLM a ses propres obligations en tant que fournisseur (documentation technique, instructions d'utilisation), mais le déployeur ne peut pas s'en remettre au fournisseur pour satisfaire à ses propres obligations de transparence. De plus, l'exploitant du stade doit s'assurer que le traitement des données du chatbot est conforme au GDPR — la base légale du traitement des données personnelles partagées dans la conversation doit être établie, et la politique de confidentialité doit refléter ce traitement basé sur l'IA.
Q3. La plateforme d'analyse WiFi d'une chaîne de magasins de détail élabore des profils de clients individuels depuis deux ans, en combinant les données de session WiFi (adresse MAC de l'appareil, temps de visite, fréquence des visites, emplacement dans le magasin) avec les données CRM (historique d'achat, niveau du programme de fidélité) pour alimenter un modèle d'IA qui prend des décisions automatisées sur les offres promotionnelles à afficher à chaque client sur le Captive Portal. Le nouveau responsable de la conformité de la chaîne doit évaluer si ce système est à haut risque en vertu de la disposition sur le profilage individuel de l'Annexe III de l'IA Act de l'UE. Quelle est la méthodologie d'évaluation et le résultat probable ?
Conseil : Appliquez le test de profilage individuel de l'Annexe III : le système d'IA effectue-t-il un traitement automatisé de données à caractère personnel pour évaluer des aspects des préférences, des intérêts, du comportement ou de la localisation d'une personne ? Examinez ensuite si les décisions automatisées sont suffisamment importantes pour déclencher la classification à haut risque.
Voir la réponse type
La méthodologie d'évaluation suit trois étapes. Premièrement, confirmer que le système est un système d'IA (et non un simple moteur basé sur des règles) — si la décision promotionnelle est prise par un modèle de machine learning plutôt que par un moteur de règles déterministes, il s'agit d'un système d'IA. Deuxièmement, appliquer le test de profilage individuel de l'Annexe III : le système traite des données à caractère personnel (données de session WiFi, données CRM) pour évaluer les préférences, les intérêts, le comportement et la localisation d'un individu. Cela correspond à la définition du profilage individuel. Troisièmement, évaluer si le système est répertorié parmi les cas d'usage de l'Annexe III — la catégorie la plus pertinente étant "l'accès et le bénéfice de services publics et privés essentiels", qui inclut les systèmes d'IA utilisés pour évaluer l'éligibilité aux services. La question de savoir si les décisions relatives aux offres promotionnelles constituent un "accès à des services" est une zone grise ; si le système d'IA peut refuser à un client l'accès à une offre promotionnelle qui affecte matériellement sa décision d'achat, les régulateurs peuvent considérer que cela est significatif. Le résultat probable est que le système doit être traité comme potentiellement à haut risque et qu'une évaluation formelle doit être menée. La chaîne doit contacter le fournisseur de la plateforme pour obtenir sa classification au titre de l'IA Act, lancer une DPIA/évaluation des risques liés à l'IA et commencer à planifier la mise en conformité de l'évaluation de la conformité avant la date limite d'août 2026.
Continuer la lecture de cette série
Comment configurer SCEP pour l'enrôlement automatisé de certificats WiFi d'entreprise
Ce guide explique comment configurer SCEP (Simple Certificate Enrollment Protocol) pour l'enrôlement automatisé de certificats WiFi d'entreprise, couvrant l'architecture complète depuis la PKI et le NDES jusqu'au déploiement de profils MDM et à la validation RADIUS. Il s'adresse aux responsables informatiques, architectes réseau et CTO d'hôtels, de chaînes de vente au détail, de stades, de centres de conférence et d'organisations du secteur public qui souhaitent dépasser les clés pré-partagées et mettre en œuvre une authentification 802.1X EAP-TLS évolutive et basée sur l'identité. La plateforme cloud overlay de Purple, indépendante du matériel, s'intègre directement à cette architecture, fournissant la couche WiFi pour les invités et le BYOD qui coexiste avec votre réseau d'employés authentifié par certificat.
Le guide de l'entreprise pour SCEP : Déployer le protocole SCEP (Simple Certificate Enrollment Protocol) pour la sécurité automatisée du WiFi sur les campus
Ce guide de référence technique fournit un schéma d'architecture définitif et une stratégie d'implémentation étape par étape pour le déploiement de certificats WiFi d'entreprise à l'aide de SCEP. Il présente les différences cruciales entre SCEP et PKCS, la séquence de déploiement exacte requise pour réussir, ainsi que des stratégies concrètes de mitigation des risques pour les responsables informatiques.
Comment implémenter SCEP pour l'enrôlement automatisé de certificats WiFi
Ce guide explique comment implémenter SCEP (Simple Certificate Enrollment Protocol) pour l'enrôlement automatisé de certificats WiFi dans les établissements d'entreprise. Il couvre l'ensemble du schéma architectural - de la conception de la PKI et l'intégration MDM à la séquence de déploiement obligatoire en trois étapes - et montre aux responsables informatiques et architectes réseau comment éliminer les identifiants partagés, automatiser la gestion du cycle de vie des certificats et respecter les exigences PCI DSS et GDPR à grande échelle.