Sécurité du chat en direct : 7 points à verrouiller avant la mise en ligne de votre boîte de réception

Le chat en direct est l'un des canaux auxquels vos clients font le plus confiance. Un visiteur tape une question qui contient souvent son e-mail, son numéro de commande, parfois son adresse, de temps en temps une capture d'écran de relevé bancaire, et il compte sur le fait que l'agent en face est la bonne personne et que la transcription n'est pas exposée. Les réglages par défaut de la plupart des outils de chat en direct n'ont pas été écrits dans cet esprit. Ils ont été écrits pour une démo façon Stripe qui ne voit jamais de vrai client.

Voici la liste de contrôle de sécurité du chat en direct que nous remettons aux équipes qui utilisent Deskwoot, découpée en sept décisions qui comptent vraiment. L'essentiel fait partie de la base de sécurité de tous les forfaits Deskwoot, y compris le forfait gratuit Hacker (chiffrement en transit, hébergement dans l'UE, 2FA, le DPA et les outils pour les demandes RGPD). Une équipe qui part de zéro n'a donc rien à configurer à la main avant la mise en production. Quand une mesure demande un forfait payant, nous le précisons.

1. Chiffrez le canal et le stockage

C'est le niveau de base. Tout outil de chat en direct qui se dit sûr devrait utiliser TLS 1.2 ou plus sur chaque point d'accès que touchent les visiteurs et les agents, et AES-256 au repos pour chaque message enregistré sur disque. Deux questions à poser à votre éditeur :

• Le widget est-il servi depuis votre domaine ou depuis le CDN d'un éditeur ? Si le script de votre widget se trouve sur un CDN tiers qui n'impose pas TLS 1.3 ou qui arrive avec une CSP trop permissive, vous avez une faille dans vos couches de défense sur votre propre page. Le widget de Deskwoot est un court script qui se charge en HTTPS (TLS) depuis le propre domaine de Deskwoot et tourne dans son propre iframe, et le tableau de bord des agents envoie HSTS ainsi qu'une Content Security Policy avec une liste explicite des hôtes depuis lesquels le navigateur peut charger ou auxquels il peut se connecter.
• Les pièces jointes sont-elles chiffrées au repos ? Certains éditeurs chiffrent le texte des messages et oublient le stockage des pièces jointes. C'est pourtant là que les clients envoient des captures de remboursements, des pièces d'identité et des relevés bancaires. Deskwoot stocke les pièces jointes dans Cloudflare R2 sous juridiction de l'UE, où Cloudflare chiffre chaque objet au repos, et ne les remet que par des liens avec contrôle d'accès : une session d'agent connecté ou une URL signée de courte durée, jamais un lien public.

2. Vérifiez le client avant de révéler quoi que ce soit de sensible

La faille de sécurité la plus courante dans le chat en direct n'est pas un piratage. C'est un agent qui répond à « Où sera livrée la commande #4821 ? » sans vérifier la personne en face. Cette réponse est une donnée privée. La plupart des outils de chat en direct n'ont pas de parcours de vérification intégré, alors l'agent improvise (ou saute l'étape).

Fynn, le bot IA de Deskwoot (inclus à partir du forfait Startup), applique un modèle de vérification à 4 niveaux avant qu'un détail privé ne quitte la conversation :

• Niveau 0 : Questions publiques. « Livrez-vous au Portugal ? » obtient une réponse tout de suite. Aucune vérification.
• Niveau 1 : Contrôle du numéro de commande et du code postal. « Où en est la commande #4821 ? » demande au visiteur de donner le numéro de commande et le code postal de livraison avant que Fynn partage le statut ou le suivi. Si cela ne correspond pas, le bot ne dit rien sur la commande.
• Niveau 2 : Vérification par lien magique envoyé par e-mail. Les demandes sur un historique sensible déclenchent l'envoi d'un lien magique à usage unique à l'e-mail enregistré. Le visiteur clique et revient vérifié pour le reste de la conversation.
• Niveau 3 : Modifications. Remboursements, annulations, changements d'adresse. Fynn propose l'action et demande au visiteur de répondre « confirmer » avant de lancer l'appel d'API. Ces actions sont désactivées par défaut et s'activent espace de travail par espace de travail. Pas de remboursement accidentel à cause d'une question mal formulée.

Il vaut aussi la peine d'intégrer la vérification au parcours des agents : une mention « vérifié » bien visible dans le panneau latéral de la conversation, pour que l'agent humain sache à qui il parle.

3. Choisissez où vivent vos données

Les équipes soumises aux règles de l'UE ne peuvent pas faire tourner un chat en direct sur une infrastructure uniquement américaine et se dire conformes au RGPD. Même les équipes américaines qui vendent dans l'UE ont des obligations sur l'emplacement des données. C'est là que l'examen de la plupart des éditeurs s'effondre, car la page marketing affiche « RGPD » alors que l'accord de traitement des données, en petits caractères, passe encore par us-east-1.

L'infrastructure principale de Deskwoot tourne dans europe-west4 (Pays-Bas). Les messages des clients, les comptes des agents, les pièces jointes et les journaux d'audit restent tous dans l'UE par défaut. Le forfait gratuit Hacker n'exclut pas l'hébergement dans l'UE : vous n'avez rien à payer en plus pour garder les données de votre support sur le sol européen.

Deux points précis à vérifier avec tout éditeur de chat en direct :

• Où se trouve exactement la base de données de production ? « UE » n'est pas assez précis. Demandez la région cloud (eu-west-1, europe-west4, etc.) et chez quel fournisseur elle se trouve.
• Les appels à l'IA quittent-ils la région ? Beaucoup de plateformes « hébergées dans l'UE » envoient le traitement IA vers un point d'accès OpenAI aux États-Unis et trahissent discrètement leur propre promesse. Deskwoot envoie les requêtes IA directement à Anthropic, et Anthropic figure avec sa finalité et sa région dans l'annexe B du DPA de Deskwoot. Vous pouvez donc vérifier le trajet de l'IA comme vous vérifiez la base de données.

4. Verrouillez l'accès des agents

Le chat est chiffré, le client est vérifié, les données sont dans la bonne région, et pourtant Dave, votre ingénieur senior, peut voir chaque conversation de chaque compte parce que l'outil de chat en direct n'a qu'un seul rôle : admin. C'est la deuxième faille la plus courante.

Un chat en direct sûr a besoin d'autorisations d'agents selon le rôle :

• Périmètre restreint : les agents ne voient que les conversations qui leur sont attribuées. Pratique pour les équipes de support externalisées, où vous ne voulez pas que chaque prestataire lise l'historique de tous les clients.
• Par boîte de réception : les agents ne voient que les conversations d'une boîte de réception précise. L'équipe facturation voit les tickets de facturation, le support voit les tickets produit, et rien ne se croise.
• SSO + 2FA : des comptes d'agents protégés par votre fournisseur d'identité (Google Workspace, Microsoft Entra, Okta) avec un second facteur. Deskwoot ne propose pas de SSO. Tous les forfaits incluent la 2FA avec une application d'authentification, et sur Enterprise un administrateur peut l'imposer à chaque membre.
• Conservation du journal d'audit : chaque connexion, chaque consultation de conversation, chaque remboursement, qui l'a fait et quand. Vous pouvez enquêter après coup au lieu de rester dans le flou.

Associez le journal d'audit à une alerte Slack ou webhook sur les actions qui comptent (export du compte, suppression en masse, connexion à la place d'un autre agent), et l'équipe est alertée d'un abus à la minute où il se produit, pas lors d'une analyse 6 semaines plus tard.

5. Fixez une vraie règle de conservation des données

La plupart des plateformes de chat en direct gardent par défaut « tout, pour toujours », parce que le stockage coûte peu et qu'elles ne veulent pas débattre de conformité. Pour toujours est le mauvais réglage. Le bon réglage, c'est « assez longtemps pour aider le client, assez court pour limiter les dégâts en cas de fuite ».

Voici comment Deskwoot s'y prend :

• Historique des conversations : l'historique visible dépend du forfait : 30 jours sur Hacker, 6 mois sur Startup, 1 an sur Business, illimité sur Enterprise. Les conversations plus anciennes sont masquées, pas supprimées, et reviennent après un passage au forfait supérieur.
• Pièces jointes : supprimées automatiquement après 365 jours, indépendamment du texte du message, sauf sur Enterprise, où elles sont conservées.
• Données personnelles des visiteurs : le parcours du droit à l'effacement (RGPD, art. 17) est intégré au tableau de bord sur tous les forfaits. Retrouvez le contact par son e-mail, voyez exactement ce que l'effacement va supprimer, confirmez en tapant à nouveau l'adresse e-mail, et les données disparaissent aussitôt. L'effacement est inscrit au journal d'audit pour que vous puissiez prouver que la demande a été traitée.

6. Rendez le widget lui-même capable de se défendre

Le widget que voient vos clients est la couche que les attaquants touchent vraiment. Quelques exigences à poser :

• SRI sur le script du widget. Les empreintes Subresource Integrity lient le script à un SHA-384 connu, pour qu'un CDN compromis ne puisse pas le remplacer discrètement par du JS malveillant.
• Pas d'injection de JS inline depuis le contenu du chat. Si un agent colle « <img src=x onerror=alert(1)> » dans une réponse, le widget doit le nettoyer avant de l'afficher. Deskwoot passe chaque réponse sortante dans sanitize-html avec une liste stricte de ce qui est autorisé (pas de scripts, pas de gestionnaires on*, pas d'URI javascript:).
• Une CSP propre sur le tableau de bord des agents. Le tableau de bord tourne avec default-src 'self' et une liste explicite des services auxquels le navigateur peut se connecter. Les fournisseurs d'IA ne figurent même pas sur cette liste, car chaque appel à l'IA se fait sur le serveur. Un fichier JS compromis chez un éditeur ne doit pas pouvoir joindre le serveur d'un attaquant.
• Des cookies liés à l'origine. Les cookies de session sont en SameSite=Lax sur le tableau de bord des agents, et chaque requête qui modifie quelque chose doit passer un contrôle d'Origin. Une page malveillante ne peut donc pas utiliser le CSRF pour pousser un agent à résoudre des conversations ou à lancer des remboursements.

7. Faites la revue de sécurité dès le premier jour (avec un forfait gratuit)

Le piège dans lequel tombent la plupart des équipes : elles choisissent un éditeur de chat en direct pour une démo de 14 jours, le mettent en production, puis s'aperçoivent trois mois plus tard que la configuration de sécurité ne correspond pas à ce dont leur RSSI a besoin. À ce stade, le coût de la migration semble trop élevé pour corriger le tir.

Le moyen le moins cher d'éviter ce piège, c'est d'évaluer un outil de chat en direct sur un forfait gratuit qui inclut déjà les réglages de sécurité que vous paieriez ailleurs. Le forfait Hacker de Deskwoot est gratuit pour un agent et repose sur le même chiffrement, le même hébergement dans l'UE, la 2FA, le DPA et les outils de demandes RGPD que tous les forfaits payants. Les forfaits payants ajoutent des sièges d'agent, le bot IA avec sa vérification des clients, un historique plus long et, sur Enterprise, les journaux d'audit, les rôles personnalisés et la 2FA obligatoire.

Concrètement :

• Le forfait gratuit Hacker couvre un agent, 100 conversations par mois, Copilot IA avec 10 conversations IA par mois, l'hébergement dans l'UE, la 2FA, le DPA et les demandes RGPD.
• Startup ($4 par agent et par mois, $3.20 en facturation annuelle) ajoute plus d'agents, le bot IA Fynn avec la vérification des clients, les règles d'automatisation, 1,000 conversations et 50 conversations IA par mois, 6 mois d'historique.
• Business ($8, $6.40 en facturation annuelle) ajoute les équipes, le CSAT, la traduction, les conversations illimitées, 100 conversations IA par mois, 1 an d'historique.
• Enterprise ($12, $9.60 en facturation annuelle) ajoute les journaux d'audit, les rôles personnalisés, la 2FA obligatoire, les politiques de SLA, les jetons d'API, 300 conversations IA par mois et un historique illimité.

Cette structure permet à une équipe sécurité de faire une vraie revue, sur de vraies données et de vrais parcours, dès le premier jour, au lieu de deviner à partir de présentations commerciales.

La version en 30 secondes

Si vous comparez des outils de chat en direct en ce moment et n'avez le temps que pour un contrôle rapide, posez ces sept questions à chaque éditeur :

1. Le widget est-il servi en TLS 1.2+ avec SRI sur la balise script ?
2. Existe-t-il un parcours de vérification des clients intégré qui protège les données privées ?
3. Où se trouve physiquement la base de données de production ? Même réponse pour le traitement IA ?
4. La plateforme propose-t-elle des autorisations d'agents selon le rôle, le SSO et un vrai journal d'audit ?
5. Les durées de conservation des données se règlent-elles par boîte de réception et par type de conversation ?
6. Le widget nettoie-t-il le contenu du chat et le tableau de bord tourne-t-il avec une CSP propre ?
7. Pouvez-vous vraiment évaluer la base de sécurité sur un forfait gratuit avant d'engager un budget ?

Deskwoot répond oui à la plupart, avec trois manques que nous reconnaissons : le script du widget n'a pas d'empreinte SRI, il n'y a pas de SSO, et la durée de l'historique dépend du forfait plutôt que d'un réglage par boîte de réception. La vérification des clients arrive avec le bot IA à partir de Startup, les journaux d'audit et les rôles personnalisés avec Enterprise. Commencez l'essai de 7 jours (Enterprise, sans carte, 30 sièges dont le vôtre) pour examiner toute la configuration de sécurité sur de vraies données, ou allez directement à la page des tarifs pour le détail par forfait. La page des fonctionnalités présente le reste de la plateforme ; cet article en est la partie consacrée à la sécurité.

FAQ : les questions sur le chat en direct sécurisé que l'on nous pose le plus

Un chat en direct privé, est-ce la même chose qu'un chat en direct chiffré ? Les deux se recoupent, mais ce n'est pas la même chose. « Chiffré » désigne en général le transport (TLS) et le stockage (AES). « Privé » signifie que la conversation ne sert pas à entraîner des modèles d'IA externes, n'est pas visible par l'équipe support de l'éditeur sans accord écrit et n'est pas conservée au-delà de la règle que vous avez fixée. Deskwoot chiffre chaque connexion en TLS, chiffre en plus les identifiants, jetons et secrets stockés en AES-256-GCM, et le contenu des conversations envoyé au fournisseur d'IA sert à répondre, pas à entraîner des modèles.

Faut-il quand même un accord de traitement des données (DPA) sur le forfait gratuit ? Oui, et Deskwoot en fournit un que vous acceptez vous-même. Les utilisateurs du forfait gratuit Hacker acceptent le DPA dans Paramètres > Conformité > Accord de traitement des données et reçoivent le PDF par e-mail, sans appel commercial.

Quel est le bon réglage de conservation ? Partez sur 12 mois par défaut, et descendez à 30 jours pour toute boîte de réception qui traite des pièces d'identité, des captures de paiement ou des données de santé (PHI). Et assurez-vous que les demandes d'effacement au titre de l'article 17 du RGPD peuvent être traitées depuis le tableau de bord plutôt que par un ticket envoyé à votre éditeur.

Le widget peut-il tourner sur une boutique Shopify sans casser la CSP de la boutique ? Oui. Le widget se charge de façon asynchrone et tourne dans son propre iframe, il ne touche donc pas aux scripts de la boutique. Consultez le guide du support client pour Shopify pour la méthode d'installation.

Le bot IA lit-il les conversations précédentes pour répondre à la suivante ? Uniquement au sein de la même conversation, et les données du compte seulement après le niveau de vérification adapté. Fynn n'a aucune mémoire d'une conversation à l'autre.

Le chat en direct est-il sûr pour les clients en 2026 ?

Le chat en direct est sûr pour les clients quand la plateforme assure 4 choses : un chiffrement TLS 1.2 ou plus pour chaque message en transit, un chiffrement AES-256 au repos dans la base de données de la plateforme, aucun script tiers dans le widget qui pourrait récupérer ce qui est tapé, et des règles de conservation claires qui suppriment les messages après une durée définie.

La plupart des plateformes de chat en direct sérieuses respectent ces réglages par défaut en 2026. Les clients peuvent le vérifier en lisant la page sécurité de la plateforme (cherchez les mentions SOC 2 Type II, DPA RGPD et chiffrement au repos) et en inspectant le script du widget à la recherche de traceurs tiers inattendus (ouvrez les DevTools du navigateur et regardez l'onglet réseau). Deskwoot décrit sa configuration sur sa page sécurité : TLS (HTTPS) sur chaque connexion, AES-256-GCM pour les identifiants et jetons stockés, et aucun script tiers dans le widget.

Les agents du chat en direct peuvent-ils voir ce que vous tapez avant l'envoi ?

Certaines plateformes de chat en direct permettent aux agents de voir ce que le client tape avant qu'il appuie sur envoyer (on parle de « sneak peek » ou d'« aperçu de saisie »). Grandes plateformes qui le proposent : LiveChat.com, Intercom et Zendesk Chat. Les plateformes plus petites et axées sur la confidentialité ne le proposent généralement pas.

Deskwoot a choisi de ne pas proposer d'aperçu de saisie. La raison est double : les clients s'attendent à juste titre à ce qu'un texte qu'ils n'ont pas envoyé ne soit encore visible par personne, et le gain de productivité pour les agents est minime (un aperçu de saisie fait gagner au plus 1 à 3 secondes par réponse). Le compromis est mince, mais la confidentialité compte quand un client tape une information sensible, comme un numéro de commande, un identifiant de compte ou, pire, une donnée de paiement non masquée, avant de s'en rendre compte et de la réécrire.