Guide d'intégration du consentement aux cookies du chatbot Intercom : chat en direct conforme au GDPR en 2026

Intercom est la plateforme de messagerie professionnelle dominante pour les entreprises SaaS et les sociétés vendant directement aux consommateurs, et son widget Messenger intégré à la page — la bulle de chat qui s'ouvre sur un chat en direct, des conversations avec des bots et des visites guidées de produits — est l'une des surfaces JavaScript les plus couramment installées sur le web moderne. D'un point de vue de la confidentialité, c'est également l'une des plus conséquentes. Le script Messenger définit des cookies d'identification, suit les pages vues et les événements de session, enregistre les métadonnées de l'appareil et du navigateur, et transmet tout à l'infrastructure américaine d'Intercom dès son initialisation. Pour toute entreprise touchant du trafic EU, UK ou californien, le schéma d'installation par défaut pose le même problème de conformité qu'une installation Klaviyo ou HubSpot : un script non essentiel s'exécutant avant le consentement, traitant des données personnelles au titre du GDPR, les transférant au-delà des frontières, et créant une exposition documentable si un régulateur enquête. Ce guide détaille ce que le Messenger Intercom collecte, comment le soumettre à un CMP sans casser l'expérience de chat que les clients utilisent réellement, et où les primitives de confidentialité natives d'Intercom s'intègrent.

Ce que le Messenger Intercom collecte

Le script Messenger Intercom (chargé depuis widget.intercom.io ou js.intercomcdn.com) initialise un objet global Intercom et identifie les visiteurs avec les cookies intercom-id-* et intercom-session-*. À partir de ce moment, il capture les pages vues, le temps passé sur la page, la profondeur de défilement et les métadonnées au niveau du visiteur : agent utilisateur, système d'exploitation, navigateur, localisation dérivée de l'IP, référent, et tous les attributs personnalisés que l'application transmet via Intercom('boot', {...}) ou Intercom('update', {...}). La fonctionnalité de présence en temps réel du Messenger rapporte également l'activité du visiteur aux serveurs d'Intercom en continu pendant que la page est ouverte, générant l'une des empreintes de données en streaming les plus lourdes parmi les outils de messagerie client.

Une fois qu'un utilisateur est identifié — généralement en appelant Intercom('boot', { user_id: ..., email: ... }) après l'authentification — le script lie l'identité du visiteur à un contact Intercom connu. L'historique des conversations, les attributs et l'appartenance aux segments découlent tous de cette identification, et Intercom utilise ce lien pour piloter des campagnes de messages automatisées, des emails de cycle de vie et des visites guidées de produits in-app.

Pourquoi « Ce n'est qu'un widget de chat » ne vous dispense pas du consentement

Un argument défensif courant des équipes produit est qu'Intercom est un outil de service client, pas un traceur marketing, et que l'activité de service client se rapproche davantage de « nécessaire à l'exécution du contrat » que de « marketing nécessitant un consentement ». L'argument contient une vérité étroite mais est largement faux en pratique.

Le suivi pré-conversation n'est pas l'exécution du contrat

Une fois qu'un client initie une conversation de chat, le traitement lié à cette conversation spécifique peut raisonnablement être caractérisé comme l'exécution d'un contrat ou d'un pré-contrat au titre de l'Article 6(1)(b) du GDPR. Tout ce qui précède ce point — le suivi des pages vues, le rapport de présence, l'identification du visiteur, le message automatisé basé sur la segmentation — ne l'est pas. C'est un traitement à des fins d'analyse et de marketing nécessitant sa propre base légale.

Le Messenger s'exécute avant toute conversation

Le comportement par défaut du script est de s'initialiser au chargement de la page et de commencer à collecter des données immédiatement, bien avant que le visiteur n'ait cliqué sur la bulle de chat. Quelle que soit la base légale couvrant une session de chat active, elle ne couvre pas les données collectées pendant la période pré-conversation.

Les messages sortants automatisés sont du marketing

Les campagnes de messages automatisées d'Intercom, les emails de cycle de vie et les déclencheurs comportementaux sont des communications marketing. Ils nécessitent leur propre base légale au titre du GDPR et, aux États-Unis, du CAN-SPAM et du TCPA le cas échéant.

Contrôles de confidentialité natifs d'Intercom

Intercom expose un ensemble utile de primitives de confidentialité natives. Comme pour les autres grandes plateformes marketing, elles supposent qu'une décision de consentement existe en amont ; elles ne la collectent pas elles-mêmes.

shutdown

L'appel Intercom('shutdown') termine la session active, efface les cookies locaux et arrête tout suivi ultérieur. Associez-le à Intercom('boot') lorsque l'utilisateur accepte la catégorie marketing dans votre CMP.

L'option hide_default_launcher

Définir hide_default_launcher: true masque entièrement la bulle de chat sans décharger le script. Utile pour les pages où le chat ne devrait pas être proposé, mais ne remplace pas le fait d'empêcher réellement le chargement du script.

Contrôles de rétention des données

Les paramètres d'administration d'Intercom incluent des fenêtres de rétention configurables pour les données des visiteurs, l'historique des conversations et les journaux d'événements. Resserrer ces paramètres est une mesure de défense en profondeur en plus du filtrage au niveau du CMP.

L'option d'hébergement des données EU

Intercom propose l'hébergement des données EU pour les comptes qui l'exigent, conservant les données de conversation et de visiteur au sein de l'infrastructure EU. Cela répond à une partie significative de la préoccupation de transfert transfrontalier mais n'élimine pas l'exigence de consentement.

Intégration CMP étape par étape

Le schéma fiable consiste à différer l'initialisation du Messenger jusqu'à ce que le visiteur accepte la catégorie marketing, puis à démarrer le Messenger avec le contexte utilisateur approprié. Une fois initialisé, le Messenger fonctionne normalement ; si l'utilisateur révoque son consentement, le Messenger s'arrête proprement.

1. Supprimez l'extrait Messenger par défaut de l'en-tête

Intercom fournit un extrait d'installation qui initialise le Messenger au chargement de la page. Supprimez l'appel boot de l'en-tête du document. La balise script peut rester (avec type="text/plain" et data-category="marketing" si votre CMP utilise ce schéma), mais l'invocation Intercom('boot') doit être différée.

2. Démarrez le Messenger depuis le callback de consentement

Lorsque le CMP déclenche son événement marketing-accepté, réécrivez le type de script en text/javascript, laissez-le se charger, puis appelez Intercom('boot', { app_id: ... }). Si l'utilisateur est authentifié, incluez les paramètres d'identification dans l'appel boot.

3. Fournissez un déclencheur de chat manuel pour les utilisateurs non consentants

Un client qui a refusé le suivi marketing a toujours le droit de contacter le support. Proposez un chemin de chat alternatif — un formulaire de contact, un lien email, ou un bouton explicite « Démarrer le chat » qui charge le Messenger uniquement lorsqu'on clique dessus. Ce dernier est le schéma le plus propre : le clic explicite de l'utilisateur constitue un consentement pour l'objectif spécifique de la conversation de chat.

4. Gérez la révocation

Lorsque l'utilisateur révoque le consentement marketing, appelez Intercom('shutdown'). Cela efface les cookies locaux et arrête le suivi. Persistez l'état de consentement mis à jour pour que les chargements de page suivants le respectent.

5. Utilisez l'hébergement des données EU pour les comptes EU

Pour les comptes où la résidence des données EU importe, configurez l'espace de travail Intercom pour l'hébergement EU. Routez le trafic EU en conséquence ; si vous exploitez des espaces de travail séparés pour les clients EU et non-EU, l'intégration doit sélectionner le bon app_id au moment du démarrage.

Pièges courants

Quatre erreurs d'intégration apparaissent régulièrement dans les audits des déploiements Intercom.

Démarrage avant le consentement

Le défaut le plus courant. L'installation par défaut démarre le Messenger au chargement de la page, ce qui déclenche l'identification du visiteur et le suivi des pages vues avant toute décision de consentement. La remédiation est simple — différer l'appel boot au callback de consentement — mais la documentation d'intégration par défaut ne le signale pas assez clairement.

Considérer shutdown comme optionnel

Si un utilisateur révoque son consentement et que le Messenger n'est pas explicitement arrêté, le script continue de fonctionner avec ses cookies de session en place. Le CMP a enregistré la révocation mais le suivi sous-jacent continue. Connectez toujours shutdown à la révocation du consentement.

Regrouper support et marketing

Certaines équipes justifient le chargement du Messenger avant consentement en arguant que c'est « du support, pas du marketing ». Si le même Messenger exécute également des campagnes sortantes automatisées ou des visites guidées de produits in-app, la ligne ne peut pas être tracée. L'approche conservatrice est de soumettre entièrement le Messenger au marketing et de fournir un chemin de contact support séparé et non groupé pour les utilisateurs qui refusent le marketing.

Ignorer les charges utiles d'attributs personnalisés

Les données transmises dans les appels Intercom('update') — attributs utilisateur personnalisés, niveau d'abonnement, ancienneté du compte, identifiants utilisateur internes — sont des données personnelles transmises à Intercom. Examinez ces charges utiles pour le partage excessif ; de nombreuses intégrations transmettent plus de données d'identification que ce dont le Messenger a fonctionnellement besoin.

Liste de contrôle d'audit

Six questions concrètes à répondre pour tout déploiement Intercom touchant du trafic EU, UK ou californien.

Où Intercom s'intègre dans une architecture axée sur le consentement

Les plateformes de chat en direct et de messagerie client occupent une zone grise réglementaire que les fournisseurs n'ont pas été empressés de mettre en lumière. Le flux de données ressemble à du suivi analytique et marketing ; le discours met l'accent sur le service client. Les régulateurs ont clairement indiqué que le flux de données contrôle l'analyse, pas le discours. La bonne architecture traite le Messenger Intercom comme tout autre script tiers identifiant : soumettez-le au consentement, fournissez un chemin de contact support alternatif pour les utilisateurs qui refusent, utilisez la primitive shutdown native de la plateforme pour honorer les révocations, et configurez l'hébergement des données EU là où la résidence importe. Fait correctement, les équipes de support conservent le chat en direct et l'automatisation du cycle de vie qui rendent Intercom précieux, tandis que la posture de conformité sous-jacente cesse d'être une exposition silencieuse attendant qu'un audit la révèle.

← Blog Tout lire →