Le widget de support exige-t-il un consentement ? § 25 TDDDG

Points clés

• Le § 25 alinéa 1 TDDDG exige par principe un consentement pour déposer et lire des informations sur l'équipement terminal.
• Deux positions non tranchées coexistent : le widget comme formulaire de contact nécessaire, ou comme service soumis à consentement.
• La Datenschutzkonferenz interprète les exceptions de façon étroite et considère souvent que les scripts à chargement automatique exigent un consentement.
• Enfreindre l'exigence de consentement constitue une infraction administrative, passible d'une amende au titre du § 28 TDDDG.
• La voie la moins risquée consiste à ne charger le script de chat qu'après un accord actif de la visiteuse.

Pas un conseil juridique, mais un cadre juridique clair

Cet article ne constitue pas un conseil juridique. Il replace de façon pragmatique la situation juridique autour des widgets de support et montre quelles décisions techniques tu dois prendre en tant que responsable du support ou du site web. Quiconque intègre un widget de chat à son propre site se heurte tôt ou tard à la question du service juridique ou du délégué à la protection des données : le widget relève-t-il de la bannière de consentement, ou peut-il se charger directement ?

Le pivot juridique est le § 25 de la Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG), la loi allemande sur la protection des données dans les télécommunications et les services numériques. Cet article régit la protection de la vie privée sur les équipements terminaux et distingue précisément les opérations soumises à consentement des exceptions légales.

Le principe de l'alinéa 1. L'exception de l'alinéa 2.

Selon le § 25 alinéa 1 phrase 1 TDDDG, déposer des informations sur l'équipement terminal de l'utilisateur final ou accéder à des informations déjà stockées n'est licite que si un consentement a été donné au préalable sur la base d'informations claires et complètes¹. Selon la lecture des autorités de contrôle, la disposition est formulée de manière neutre sur le plan technologique : elle couvre donc toutes les techniques et procédés permettant de déposer et de lire des informations, par exemple le Local Storage, le Session Storage ou IndexedDB².

Le § 25 alinéa 2 numéro 2 TDDDG prévoit une exception étroite à ce principe : le consentement n'est pas requis lorsque le stockage ou l'accès est strictement nécessaire pour que le fournisseur d'un service numérique puisse fournir un service numérique expressément demandé par l'utilisateur¹.

Il importe ici de bien séparer le TDDDG et le Règlement général sur la protection des données (RGPD) : le TDDDG protège l'intégrité de l'équipement terminal indépendamment du fait que les données lues ou déposées soient personnelles. Le RGPD s'applique en plus, dès que des données personnelles telles que des adresses IP ou le contenu des conversations sont traitées.

Position 1 : le widget comme formulaire de contact nécessaire

La première interprétation juridique traite le widget de support essentiellement comme un formulaire de contact moderne, présent en permanence. Ses partisans avancent que le service client est une fonction centrale de toute offre numérique. Quiconque visite un site ou une application web s'attend à disposer d'un moyen de contact direct.

La persistance de session comme nécessité technique.

Techniquement, un widget de support interactif a besoin d'un identifiant dans le Session Storage ou le Local Storage du navigateur. Sans lui, l'historique de la conversation serait interrompu dès le changement de page ou le rechargement de l'onglet. La position 1 soutient donc : si un support est proposé, déposer cet identifiant de session purement fonctionnel est techniquement indispensable pour maintenir la conversation d'une page à l'autre.

Sur cette prémisse, les entreprises s'appuient sur l'exception du § 25 alinéa 2 numéro 2 TDDDG, qui rend le consentement superflu lorsque l'accès est strictement nécessaire pour fournir un service numérique expressément demandé par l'utilisateur¹. Le script est classé dans la catégorie Nécessaire ou Essentiel de l'outil de gestion du consentement et se charge dès la première consultation, sans que la visiteuse ait à cocher une case dans la bannière.

• Le canal de support est considéré comme une voie de contact standard, au même titre qu'un lien e-mail ou un formulaire de contact.
• L'enregistrement de l'identifiant de session sert uniquement à assurer le dialogue et ne poursuit aucun suivi.
• La fonction de transfert et d'aide est immédiatement accessible aux clientes, sans obstacle ni clic de consentement préalable.
• Le script figure dans la bannière de consentement comme service essentiel et se charge automatiquement avec la page.

Position 2 : la lecture stricte de la Datenschutzkonferenz

La Datenschutzkonferenz (DSK), l'organe commun des autorités indépendantes de protection des données de la Fédération et des Länder allemands, défend une lecture nettement plus stricte. Dans son guide destiné aux fournisseurs de télémédias, elle retient que le § 25 alinéa 1 pose le principe de l'exigence de consentement et que seules les deux exceptions étroitement délimitées de l'alinéa 2 y dérogent². Le législateur s'est délibérément tenu au plus près du texte européen et n'a ajouté aucune autre exception, de sorte que peu de services peuvent être intégrés sans consentement².

Un chargement automatique sans interaction n'est pas une demande expresse.

De l'avis des autorités de contrôle, c'est précisément là que le bât blesse avec un widget de chat à chargement automatique : la visiteuse ouvre un site pour se renseigner sur un produit ou lire un article. À cet instant, elle n'a pas encore expressément demandé le service de support. Selon la lettre de la loi, l'exception ne s'applique que si l'accès est strictement nécessaire pour fournir un service numérique expressément demandé par l'utilisateur¹. La Datenschutzkonferenz souligne que ces deux éléments sont indissociables et que la stricte nécessité doit toujours s'apprécier au regard du service concrètement demandé, ce qui impose un examen granulaire de chaque fonction du site². Si le script se charge déjà en arrière-plan et dépose un identifiant d'appareil avant que l'utilisatrice ait cliqué activement sur l'icône de chat, le critère de la demande expresse fait défaut selon cette lecture.

Les autorités relèvent en outre que de nombreux scripts de widget courants collectent déjà des données d'appareil et de navigateur lors de l'initialisation, transmettent des adresses IP à des serveurs tiers ou chargent des polices et des ressources externes. L'exigence de consentement s'applique indépendamment du caractère personnel ou non des informations stockées ou lues². S'y ajoute le moment : le consentement doit exister avant tout accès à l'équipement terminal. Selon cette lecture stricte, charger un widget de façon systématique sur chaque sous-page est soumis à consentement.

Conséquences pratiques : chargement au clic ou catégorie dans la bannière ?

La qualification juridique n'est pas un exercice théorique. Elle dicte exactement la manière dont ton widget doit être implémenté techniquement et raccordé à ton système de gestion du consentement. Qui tranche en faveur de l'une des deux lectures doit retenir l'architecture technique correspondante.

Option A : chargement immédiat comme service essentiel.

Si ton entreprise qualifie le widget de techniquement indispensable, tu inscris le script dans le groupe Essentiel ou Nécessaire de ton outil de consentement. Le widget se charge de façon asynchrone à l'ouverture de la page. La visiteuse voit aussitôt le bouton de support dans le coin de l'écran. L'avantage : une disponibilité maximale et aucun obstacle pour qui cherche de l'aide.

Option B : pilotage par la bannière de consentement.

Si ton entreprise suit la position des autorités de protection des données, le widget relève de la catégorie Fonctionnel ou Médias externes. En pratique : le script est bloqué par la bannière et n'est injecté que lorsque l'utilisatrice clique activement sur Tout accepter ou sélectionne Fonctionnel. Si la visiteuse refuse, le widget reste totalement invisible pour elle. Dans ce cas, il est recommandé de proposer des moyens de contact statiques en pied de page ou un centre d'aide public comme solution de repli.

Option C : la solution en deux clics avec espace réservé.

Une alternative élégante au blocage par bannière est le chargement au clic. Ici, aucun script externe ni cookie n'est chargé au départ. La page ne contient qu'une icône locale servant d'espace réservé. Lorsque la visiteuse clique activement sur cette icône de chat, elle confirme par là même sa demande expresse du service de support. Seul ce clic déclenche le chargement dynamique du script du widget. Cela correspond à la lettre de l'exception du § 25 alinéa 2 numéro 2 TDDDG, qui n'exempte l'accès que pour un service numérique expressément demandé¹.

1. 01Variante 1 (essentiel) : le script se charge directement. Grande accessibilité, exige une documentation solide dans l'entreprise.
2. 02Variante 2 (opt-in par bannière) : le script ne se charge qu'en cas d'accord dans la bannière. Un refus fait perdre le canal de chat.
3. 03Variante 3 (chargement en deux clics) : l'espace réservé ne charge le script qu'en cas d'interaction active. Grande sécurité juridique, visibilité préservée.

Documentation : pourquoi une simple décision ne suffit pas

Quelle que soit la voie retenue par ton équipe : une décision informelle dans le Slack du support ou un accord oral ne tiendront pas devant un contrôle des autorités. L'art. 5 § 2 RGPD impose la responsabilité. Tu dois pouvoir démontrer et justifier à tout moment pourquoi un outil est déployé de cette manière.

Inscription au registre des activités de traitement.

Tout système de support utilisé doit impérativement figurer au registre des activités de traitement, conformément à l'art. 30 RGPD. Les finalités du traitement, les catégories de personnes concernées, les destinataires des données, les durées de conservation et les bases juridiques retenues au titre du TDDDG et du RGPD doivent y être consignés de façon transparente.

Par ailleurs, la politique de confidentialité de ton site doit détailler l'usage du widget. Si des identifiants y sont déposés, la durée de conservation, le fonctionnement et les prestataires impliqués doivent être nommés avec précision. C'est aussi la base pour répondre avec assurance et dans les délais aux demandes ultérieures des utilisateurs ou aux demandes d'accès au titre du RGPD.

• Une justification documentée de la qualification au titre du § 25 TDDDG (essentiel, opt-in par bannière ou deux clics).
• La tenue à jour de l'inscription au registre des activités de traitement conformément à l'art. 30 RGPD.
• Une clause complète dans la politique de confidentialité, nommant le prestataire, les durées de conservation et la finalité des données.
• La conclusion d'un contrat de sous-traitance au titre de l'art. 28 RGPD avec le fournisseur du widget.

La voie la moins risquée pour les responsables de site

Qui veut réduire le risque juridique doit peser froidement les conséquences possibles. Les manquements aux prescriptions du § 25 alinéa 1 TDDDG ne sont pas des broutilles. Selon le § 28 alinéa 1 numéro 13 combiné à l'alinéa 2 TDDDG, déposer des informations ou y accéder sans consentement peut être sanctionné d'une amende pouvant atteindre trois cent mille euros⁴.

Le risque de mises en demeure par des associations et des concurrents.

Outre les amendes administratives, les scripts intégrés sans transparence exposent toujours à des mises en demeure fondées sur le droit de la concurrence, émanant d'associations de consommateurs ou de concurrents. Les scripts qui déposent des cookies de suivi sans consentement dans la bannière, ou transfèrent des données vers des pays tiers sans niveau de protection adéquat, sont la cible des robots automatisés.

La voie de loin la moins risquée est donc double : soit tu intègres le widget avec une véritable logique en deux clics, de sorte qu'aucune donnée ne circule avant le clic sur le chat, soit tu classes le widget dans la catégorie soumise à consentement de ta bannière. Si en revanche tu veux charger le widget directement comme essentiel, assure-toi que le fournisseur ne pratique aucun suivi tiers, que les données sont traitées intégralement dans l'UE et que la justification est documentée sans lacune au registre des activités de traitement.

Support par IA conforme au RGPD avec Comlayer

Si tu veux automatiser un service client moderne sans t'aventurer dans des zones grises juridiques, tout dépend de la base technique. L'essentiel est une solution qui sépare proprement l'interface du traitement des données et te laisse toute latitude pour l'intégration.

Un script léger et des modes de chargement souples.

Le widget de Comlayer s'intègre au moyen d'un extrait JavaScript asynchrone. Tu décides toi-même si l'extrait se charge directement dans le code source, s'il est libéré par ton système de gestion du consentement après accord, ou s'il n'est initialisé dynamiquement qu'au moyen d'un événement de clic sur ta page. La liste blanche de domaines garantit que ta clé de widget ne peut pas être détournée sur des domaines tiers.

À quoi ressemble une telle décision une fois prise, on peut le lire chez Comlayer même. Dans son propre registre de consentement, le chat de support est classé comme nécessaire au titre du § 25 alinéa 2 numéro 2 TDDDG, au motif qu'il est l'unique canal de support de ce site et qu'il est donc traité comme un formulaire de contact. La position contraire figure expressément à côté : la Datenschutzkonferenz range les widgets de chat à chargement automatique parmi les services soumis à consentement, parce que le script se charge sans intervention de la visiteuse et dépose un identifiant. Qui en juge autrement déplace l'entrée dans la catégorie fonctionnelle, subordonne le chargement au consentement et incrémente la version de la bannière afin que la question soit reposée. Cela non plus n'est pas une question de droit tranchée, mais une décision motivée et documentée — précisément celle que décrit cet article.

Traitement dans l'UE et aucun entraînement de modèles.

Derrière le widget travaille une infrastructure européenne propre en matière de sécurité et de protection des données : les conversations, les pièces jointes et le traitement par l'IA s'exécutent dans des centres de données européens. Un contrat de sous-traitance au titre de l'art. 28 RGPD est fourni directement. Un point essentiel pour les entreprises : tes données clients et tes conversations de support ne servent pas à entraîner des modèles d'IA. Les réponses reposent sur le RAG (Retrieval-Augmented Generation) et fournissent toujours le lien vers la source.

Les formules sont structurées de façon transparente : la formule Free permet de démarrer gratuitement avec le widget de support, le centre d'aide et deux places d'équipe. La formule Pro s'adresse aux équipes qui exploitent le support par IA en production et comprend 500 réponses d'IA incluses ainsi qu'un domaine propre pour le centre d'aide. Pour des volumes plus élevés, la formule Scale offre 5 000 réponses d'IA incluses.

• Intégration souple : chargement direct, couplage à la bannière ou déclencheur en deux clics via JavaScript.
• Hébergement et traitement par l'IA dans des régions européennes, avec contrat de sous-traitance.
• Aucun entraînement de modèles d'IA publics avec tes conversations clients.
• Des modèles tarifaires transparents, de la formule Free gratuite à Pro et Scale, avec un prix de base mensuel, un prix par place et des réponses d'IA facturées à l'usage.

Questions fréquentes