Comment évaluer les exigences relatives aux iframes, aux cookies et à la confidentialité avant d’ajouter WebChat à votre site
Une revue pratique avant lancement pour WebChat intégré : cartographiez les données et le stockage du navigateur, évaluez le consentement et les informations, testez les états d’échec et attribuez des responsables.
Pourquoi WebChat intégré exige une revue de lancement, et pas seulement un extrait de code
L’ajout d’un widget WebChat modifie davantage que la mise en page d’un site. Il peut créer un nouveau canal de contact pour les visiteurs, collecter le contenu des messages et des coordonnées, utiliser du stockage côté navigateur, transmettre des données à des prestataires et produire des enregistrements de conversations utilisés par les équipes de support. Il s’agit de décisions opérationnelles, de confidentialité et de sécurité, autant que de décisions de mise en œuvre.
Commencez par un exercice de cartographie des données. Identifiez les informations qui entrent dans le chat, où elles circulent, qui peut y accéder, ce qui se passe lorsqu’un flux automatisé demande des informations ou envoie un fichier, et pendant combien de temps les enregistrements restent disponibles. Un extrait de code ne peut pas déterminer vos finalités de traitement, votre base juridique, votre calendrier de conservation, votre liste de destinataires ni les voies d’exercice des droits que vous proposez aux visiteurs.
Pour webchat.vip, le propriétaire du site configure un widget WebChat installable, personnalisable et multilingue. Les conversations sont traitées dans une boîte de réception partagée qui prend également en charge WhatsApp, avec des contrôles concernant les opérateurs, les services, l’acheminement, les horaires, les niveaux de service, les modèles et les étiquettes. Le propriétaire du site doit décider de la manière dont ces fonctionnalités sont configurées et gouvernées.
- Désignez un responsable de la mise en œuvre, un examinateur de la confidentialité, un examinateur de la sécurité et un responsable des opérations de support.
- Ne lancez pas le service avant que chaque responsable ait accepté les décisions relevant de son domaine.
- Traitez les changements en production de la configuration du widget, des flux automatisés, de l’acheminement, des fichiers, de l’accès aux analyses et de la conservation comme des changements soumis à revue, et non comme de simples modifications de conception.
Cartographiez les parties et les flux de données avant de décider de ce que vous devez communiquer
Documentez le parcours réel plutôt qu’un parcours générique de widget. Un visiteur peut ouvrir le widget sans envoyer de message, saisir un nom ou une coordonnée, soumettre une demande de support, recevoir une réponse automatisée, être orienté vers un service ou être transféré à une personne. Chaque parcours peut influencer l’inventaire des données et l’avis de confidentialité.
Distinguez au minimum le visiteur, votre organisation en tant que propriétaire du site, webchat.vip en tant que fournisseur de la plateforme WebChat, les utilisateurs de support autorisés, ainsi que tout canal connecté ou prestataire intervenant dans la configuration que vous avez choisie. Ne présumez pas que le rôle, les destinataires, les emplacements ou les sous-traitants ultérieurs d’un prestataire peuvent être déduits du widget visible.
webchat.vip enregistre des analyses opérationnelles, des journaux de conversation, des évaluations et des rapports exportables. Il prend également en charge des flux automatisés capables d’envoyer des messages et des fichiers, de collecter des réponses validées, d’orienter selon des branches, de transférer et de passer la main à des personnes. Décidez lesquelles de ces fonctions vous activerez, quelles données elles nécessitent et si elles sont adaptées au type de demande.
- Pour chaque donnée, consignez : la source, la finalité, le système ou rôle destinataire, le groupe d’accès, la règle de conservation et le processus de suppression ou de restitution.
- Séparez le contenu fourni par le visiteur des données techniques créées par le navigateur ou le fonctionnement du service.
- Déterminez si un message pourrait contenir des données de catégorie particulière, des informations financières, de santé, d’authentification ou d’autres informations sensibles. Si tel est le cas, obtenez une revue spécialisée en confidentialité et sécurité avant le lancement.
- Pour les fichiers envoyés par les flux automatisés, consignez les types de fichiers prévus, le processus de traitement du contenu et les personnes autorisées à y accéder. webchat.vip stocke les fichiers dans un sous-compte Apification Cloud isolé pour chaque service omnicanal.
Iframe ou intégration directe : comprendre la séparation sans la surestimer
Une iframe et un script tiers inclus directement ne sont pas équivalents. Une iframe inter-origines crée une séparation dans le navigateur : les scripts sont soumis à la politique de même origine, tandis qu’une communication inter-origines contrôlée peut intervenir via des mécanismes tels que Window.postMessage(). Le stockage du navigateur est également généralement séparé par origine.
Un script tiers inclus directement dans la page occupe une position technique différente. Il peut accéder aux autres scripts et aux données de la page et fonctionne de fait comme du code de première partie. Cela rend particulièrement importantes l’approbation de la source, la gestion des changements et la revue de la politique de sécurité du contenu.
Aucun de ces modèles ne répond à l’ensemble des questions de confidentialité. Une iframe n’établit pas de finalités licites, ne minimise pas les données collectées, ne détermine pas la conservation et ne garantit pas un comportement uniforme de tous les paramètres de confidentialité du navigateur. Examinez l’intégration réellement fournie pour votre canal configuré, y compris les attributs de cadre, les origines autorisées, les messages échangés avec la page hôte et les requêtes réseau externes.
- Demandez à l’ingénierie d’identifier si le déploiement utilise un script direct, une iframe ou les deux.
- Si une iframe est utilisée, consignez son origine source, ses attributs sandbox, ses autorisations et ses voies de communication avec la page hôte.
- Comprenez que l’omission de allow-same-origin d’un sandbox d’iframe donne au contenu encadré une origine spéciale et peut empêcher l’accès aux cookies, au stockage de données et à certaines API JavaScript.
- N’ajoutez pas d’autorisations d’iframe étendues simplement pour résoudre un problème de test ; établissez quelle fonctionnalité nécessite l’autorisation et approuvez la configuration pratique la plus restrictive.
Déterminez si le consentement est requis selon la finalité et la juridiction
Ne prenez pas de décision générale selon laquelle tout stockage de chat est exempté, ou que chaque interaction technique nécessite le même traitement du consentement. Selon le résumé par le CEPD des règles européennes, le stockage ou l’accès aux cookies exige généralement une information adéquate et un consentement, à l’exception des cookies techniquement nécessaires. L’évaluation dépend des règles applicables et de la finalité spécifique.
Distinguez le stockage réellement nécessaire pour fournir un service que le visiteur a expressément demandé du suivi, de la mesure ou d’autres finalités facultatives et non essentielles. La commodité de mise en œuvre n’est pas le critère de nécessité technique. Demandez à un conseil spécialisé en confidentialité d’évaluer les finalités dans les juridictions où vous exercez vos activités.
Séparez également l’évaluation du stockage navigateur de la base juridique du traitement des données personnelles. Si le consentement est la base juridique que vous avez choisie pour le traitement, expliquez qu’il peut être retiré et comment le retirer. Le retrait doit être aussi facile que le consentement.
- Définissez ce qui se produit avant le consentement, après l’acceptation, après le refus et après le retrait.
- Assurez-vous que le mécanisme de consentement peut empêcher l’activité facultative avant que le choix requis ne soit fait, lorsque cela s’applique.
- Ne faites pas de l’acceptation d’un suivi facultatif une condition d’accès au support ordinaire, sauf si votre revue juridique soutient cette approche.
- Testez à nouveau après qu’un visiteur modifie ses préférences de consentement, supprime les données du navigateur ou utilise la navigation privée.
Rendez l’avis de confidentialité spécifique à votre service réel
Un avis de confidentialité pour WebChat doit décrire le traitement de votre organisation, et non se contenter de répéter la description d’un widget. En vertu des exigences de transparence du RGPD et, lorsque le UK GDPR s’applique, de ce régime, les informations requises dépendent de la juridiction et de la situation de votre organisation. Elles peuvent inclure l’identité et les coordonnées du responsable du traitement, les coordonnées applicables du DPO, les finalités, la base juridique, les destinataires ou catégories de destinataires, les durées ou critères de conservation, les droits et une voie de réclamation auprès de l’autorité de contrôle compétente lorsque cela est requis.
Établissez si des transferts de données vers un pays tiers ou une organisation internationale sont pertinents pour votre configuration et, le cas échéant, le mécanisme de transfert ou les garanties applicables. Confirmez-le au moyen de la documentation actuelle du prestataire et des documents contractuels, plutôt que par des hypothèses sur l’hébergement ou la langue d’une interface.
Facilitez l’accès à cette information avant ou au moment où les personnes fournissent des informations dans le chat. Employez un langage clair, expliquez ce qu’un opérateur peut voir et évitez de promettre une confidentialité ou des résultats de réponse que votre processus de support ne peut pas garantir de manière constante.
- Ajoutez un lien vers l’avis depuis le widget ou une information affichée à proximité, ainsi que depuis les informations générales de confidentialité du site.
- Indiquez un moyen pratique de contact pour les demandes relatives à la confidentialité et un autre moyen pour le support urgent ou les problèmes de sécurité.
- Décrivez la conservation par une durée définie ou par les critères employés pour la déterminer ; ne vous appuyez pas sur un paramètre par défaut de plateforme non documenté.
- Examinez les avis chaque fois que les finalités, les destinataires, l’automatisation, les fichiers, les rôles d’accès ou les règles de conservation changent.
Posez des questions de mise en œuvre qui ne présument pas des paramètres par défaut du prestataire
Envoyez un questionnaire écrit au prestataire et conservez sa réponse avec vos preuves de lancement. L’objectif n’est pas d’obtenir une assurance générale ; il est de confirmer le comportement actuel de l’intégration que vous avez sélectionnée et les accords contractuels qui s’y appliquent.
Lorsqu’un prestataire traite des données personnelles pour votre compte, l’article 28 du RGPD renvoie à des sujets pratiques, dont les instructions documentées, les engagements de confidentialité, les mesures de sécurité, les sous-traitants ultérieurs, l’assistance concernant les demandes d’exercice des droits, la suppression ou la restitution des données et les informations d’audit. Votre équipe juridique doit déterminer quel accord et quelles preuves sont nécessaires dans votre situation.
Demandez à webchat.vip comment se comporte la configuration de widget que vous avez choisie, tout en maintenant une répartition claire des responsabilités : votre organisation décide quelles données demander, quelles automatisations et quels services activer, qui reçoit les conversations, ainsi que de l’utilisation et de la conservation des enregistrements.
- Quels domaines, scripts, cadres et points de terminaison réseau sont requis pour le widget configuré ?
- Quels cookies ou autres stockages navigateur peuvent être créés ou consultés, sous quelles origines et pour quelles finalités ?
- Quels champs de données les flux automatisés peuvent-ils collecter, et comment le propriétaire du site peut-il limiter la collecte et garantir le transfert à une personne ?
- Qui peut accéder à la boîte de réception partagée, aux rapports, aux exportations et aux fichiers, et quel modèle de contrôle d’accès s’applique à chacune de ces zones ?
- Quels sont les dispositifs actuels relatifs aux sous-traitants ultérieurs, aux transferts internationaux, à la sécurité, à la suppression ou restitution et à la notification d’incident au titre de l’accord applicable ?
- Quels changements de l’intégration ou du service du prestataire exigent de nouveaux tests ou une notification ?
Appliquez des contrôles de sécurité et concevez pour le choix du client
Exigez HTTPS pour le site hôte et examinez l’intégration configurée au regard de votre politique de sécurité du contenu. La sécurité doit approuver les sources de scripts et de cadres requises, les destinations de connexion et toute directive nécessaire avant la mise en production. Ne résolvez pas un problème de déploiement en autorisant largement des sources non examinées ou en affaiblissant la politique sur l’ensemble du site.
Appliquez le principe du moindre privilège à l’administration comme exigence opérationnelle. webchat.vip permet aux équipes d’organiser les opérateurs, les services, l’acheminement, les horaires, les niveaux de service, les modèles et les étiquettes. Utilisez ces contrôles pour favoriser une affectation opérationnelle appropriée, examinez les accès lorsque les rôles du personnel changent et assurez-vous que l’acheminement n’envoie pas les demandes sensibles vers une file inappropriée. Confirmez le modèle réel de contrôle d’accès de la plateforme avant de vous y fier pour restreindre l’accès aux conversations, rapports, exportations ou fichiers.
Un visiteur qui ne peut pas ou ne souhaite pas utiliser le chat doit tout de même disposer d’une voie de support fonctionnelle. Proposez une alternative, telle qu’un formulaire de contact, une adresse e-mail, une ligne téléphonique ou un autre canal approprié. Veillez à ce que l’information affichée par le widget, le parcours de consentement et la voie alternative soient utilisables au clavier et compréhensibles sur les petits écrans.
- Revue sécurité : points de terminaison HTTPS approuvés, compatibilité avec la CSP, autorisations d’iframe examinées et absence de scripts tiers directs non approuvés.
- Revue support : attentes de disponibilité visibles, comportement hors horaires, responsabilité des services et critères de transfert à un humain.
- Revue accessibilité : utilisation au clavier seul, ordre de tabulation, focus visible, erreurs compréhensibles, mise en page mobile et parcours sans chat.
- Revue confidentialité : aucun champ inutile, accès clair à l’avis et voie alternative qui n’exige pas le consentement au suivi facultatif.
Questions fréquentes
L’utilisation d’une iframe supprime-t-elle les obligations de confidentialité liées à WebChat ?
Non. Une iframe inter-origines peut créer une séparation dans le navigateur et séparer le stockage par origine, mais elle ne détermine ni vos finalités, ni votre base juridique, ni les destinataires, ni la conservation, ni le contenu de l’avis, ni les obligations de consentement. Examinez l’intégration spécifique et le traitement de votre organisation.
Les cookies WebChat sont-ils toujours essentiels ?
Non. Selon le résumé par le CEPD des règles européennes, le stockage ou l’accès aux cookies exige généralement une information et un consentement, sauf lorsqu’il est techniquement nécessaire. Évaluez chaque élément de stockage selon sa finalité réelle et la juridiction applicable ; ne le qualifiez pas d’essentiel simplement parce qu’il est utile au chat.
Quel stockage navigateur une revue WebChat doit-elle couvrir ?
Incluez au minimum les cookies, localStorage et sessionStorage. Consignez l’origine, la finalité, le moment de création, la persistance et les attributs pertinents des cookies. Testez les parcours réels des visiteurs, car la configuration peut modifier les données stockées ou consultées.
Que doit-il se passer si les cookies sont bloqués ou si le stockage est indisponible ?
Testez le widget configuré dans des états de blocage des cookies et de navigation privée avant le lancement. Définissez un comportement d’échec compréhensible et proposez une voie de contact alternative claire. Transmettez les échecs non résolus d’accès au stockage au responsable de la mise en œuvre et au support du prestataire avant la mise en production.
Qui doit approuver le lancement de WebChat ?
Le propriétaire du site ou responsable de la mise en œuvre doit coordonner l’approbation par les équipes de confidentialité, de sécurité, d’opérations de support et d’ingénierie web. La confidentialité approuve les décisions relatives aux données, à l’avis, à la conservation et au consentement ; la sécurité approuve les contrôles d’intégration ; le support est responsable de l’acheminement, des effectifs et de l’escalade humaine ; l’ingénierie est responsable du déploiement testé et du retour en arrière.
Quand un flux WebChat automatisé doit-il être transféré à une personne ?
Définissez les règles de transfert avant le lancement. Transférez lorsqu’une demande exige un jugement, concerne une réclamation ou une demande d’exercice des droits, implique des informations sensibles, ne peut pas être résolue par le flux ou indique un problème urgent de sécurité ou de sécurité du compte. Donnez aux visiteurs une voie claire pour contacter une personne plutôt que de laisser entendre que l’automatisation peut résoudre tous les cas.
Sources et lectures complémentaires
Références primaires et reconnues utilisées pour vérifier la base factuelle de ce guide.
- General Data Protection Regulation (GDPR), Regulation (EU) 2016/679 — EUR-Lex / Publications Office of the European Union
- EDPB FAQ: Cookies and consent — European Data Protection Board
- EDPB Guidelines 2/2023 on the technical scope of Article 5(3) of the ePrivacy Directive — European Data Protection Board
- What privacy information should we provide? — Information Commissioner's Office
- Storage limitation — Information Commissioner's Office
- Iframe element reference — MDN Web Docs
- Privacy on the web — MDN Web Docs
- Web Storage API — MDN Web Docs
- Using HTTP cookies — MDN Web Docs
- Storage Access API — MDN Web Docs