Sécurité des données d'un chatbot : de la saisie au CRM

« Où vont les conversations de notre chatbot ? » Réponse au DPO ou au RSSI qui pose la question : elles transitent par le navigateur, les serveurs de l’éditeur, le fournisseur du modèle de langage et le CRM connecté, et se stockent à plusieurs de ces endroits. Chacun se contrôle, et la sécurité des données d’un chatbot se joue là.

Sécurité des données d’un chatbot : le trajet d’un message

Un client tape sa question dans la fenêtre de discussion d’un site d’assurance. Avant que la réponse s’affiche, son message a déjà traversé plusieurs systèmes opérés par des entités distinctes. Le chatbot actuel repose le plus souvent sur un modèle de langage, l’une des avancées de l’intelligence artificielle récentes, qui tourne rarement dans vos murs.

Quatre lieux méritent chacun une ligne dans votre registre des traitements :

• le navigateur de l’utilisateur, où le widget garde l’historique de la session dans un cookie ou le stockage local, parfois lisible sur un poste partagé ;
• les serveurs de l’éditeur, qui hébergent transcriptions, journaux et console d’administration où les échanges se relisent ;
• le fournisseur du modèle de langage, qui reçoit à chaque tour la question, l’historique récent et les extraits documentaires utiles ;
• le CRM connecté, où un résumé ou un ticket enrichit la fiche client, avec les droits d’accès du CRM et non ceux du chatbot.

S’y ajoute souvent une base vectorielle, qui indexe vos documents internes. L’ANSSI, dans ses recommandations de sécurité pour un système d’IA générative publiées le 29 avril 2024, range requêtes des utilisateurs et réponses du modèle parmi les données à cartographier dès la conception. Ces données des conversations contiennent tout ce que l’utilisateur a choisi d’écrire, y compris ce que personne ne lui demandait.

Service client : les trois garde-fous d’un chatbot d’entreprise sécurisé

Sur un parcours de service client, un chatbot d’entreprise sécurisé tient trois engagements. Il trace les échanges : l’article 5 du RGPD oblige le responsable du traitement à démontrer qu’il respecte les principes, et une conversation sans trace ne se démontre pas. Il recueille le consentement quand la finalité l’exige : la CNIL distingue depuis février 2021 le traceur déposé dès l’affichage de la page, soumis à consentement, de celui déposé quand l’utilisateur ouvre lui-même la fenêtre, exempté s’il sert exclusivement au chatbot. Il transfère enfin les cas sensibles à un humain, car pour la CNIL une conversation avec un chatbot ne peut conduire à elle seule à des décisions importantes pour la personne.

Ces garde-fous se paramètrent avant la mise en production, et une offre sérieuse les expose noir sur blanc. La page qui présente les chatbots Webotit détaille ces garde-fous : traçabilité des échanges, consentement, règles d’escalade configurées selon les règles RGPD de l’entreprise, reprise humaine avec le contexte de la conversation transmis au conseiller. Webotit y décrit aussi un tableau de bord des motifs et des escalades, une base concrète pour le DPO qui doit rendre compte du dispositif.

En pratique, la reprise humaine se règle par motifs : réclamation, contestation, situation de fragilité, donnée de santé. Le conseiller reçoit l’historique et un résumé, sans faire répéter au client ce qu’il vient d’écrire : autant de copies en moins dans vos outils.

Hébergement : SaaS, cloud de confiance ou serveurs internes

Le lieu d’hébergement règle une bonne partie des questions de votre DPO. Trois modèles coexistent :

• en SaaS, l’éditeur opère la plateforme, et le contrat doit décrire son exploitation ;
• sur un cloud public, l’ANSSI recommande de privilégier une offre qualifiée SecNumCloud si les données sont sensibles, si l’impact métier est critique ou si les utilisateurs ne sont pas considérés comme de confiance ;
• sur l’infrastructure de l’entreprise, les données restent chez vous, mais mises à jour, supervision et cloisonnement vous reviennent.

Un chatbot ouvert au public remplit au moins le dernier critère : ses utilisateurs sont, par définition, inconnus.

Autre point : une interface installée en France peut appeler un modèle de langage opéré hors de l’Union européenne. Demandez le schéma complet des flux, pas seulement l’adresse du centre de données. Le guide de l’ANSSI ajoute trois mesures : cloisonner le système d’IA dans des environnements dédiés, placer un service exposé sur Internet derrière une passerelle sécurisée, prévoir un mode dégradé sans IA.

Chatbot RGPD : minimisation, base légale et conservation

Un chatbot RGPD n’existe pas en soi : la conformité tient au traitement, à ce que l’entreprise décide de collecter, pour quoi et combien de temps.

Minimisation : ouvrir seulement les champs utiles

Le RGPD exige des données « adéquates, pertinentes et limitées à ce qui est nécessaire ». Pour un chatbot, la règle devient un choix de conception : un menu plutôt qu’un champ libre, aucun numéro de contrat pour une question générale, aucune connexion au CRM pour un parcours d’information. Un chatbot ne doit recevoir que les données que son périmètre exige, et le réglage de sécurité le plus efficace reste de ne pas lui faire collecter ce dont il n’a pas besoin. Une donnée jamais saisie ne fuira jamais.

Base légale et information de l’utilisateur

La base légale suit la finalité, pas l’outil : suivre un dossier en cours relève en général de l’exécution du contrat, une réutilisation commerciale des échanges appelle sa propre base. L’utilisateur doit savoir qui traite ses messages, pourquoi, combien de temps et comment exercer les droits rappelés dans notre article sur la protection des données personnelles. Le règlement européen sur l’IA ajoute une obligation de transparence, applicable depuis août 2026 selon la Commission européenne : la personne doit savoir qu’elle échange avec une machine.

Durée de conservation : une règle par finalité

Dans ses conseils sur les chatbots, la CNIL ne fixe aucune durée chiffrée : elle demande de conserver les données le temps nécessaire à la finalité, et distingue l’échange à effacer après la conversation, comme une question d’achat, de la réclamation qui justifie une conservation plus longue. Traduisez cette logique en purges automatiques chez l’éditeur, chez le fournisseur du modèle et dans le CRM : une durée de conservation appliquée à un seul de ces lieux laisse des copies vivre ailleurs.

L’éditeur, sous-traitant au sens de l’article 28

Dans la plupart des projets, l’entreprise reste responsable du traitement et l’éditeur agit comme sous-traitant, pour votre compte et sur vos instructions. L’article 28 du RGPD fixe le contenu minimal du contrat :

• un traitement sur instruction documentée de votre part ;
• la confidentialité des personnes autorisées à lire les échanges ;
• les mesures de sécurité prévues à l’article 32 ;
• le recours à un autre sous-traitant après autorisation écrite préalable ;
• l’assistance pour répondre aux demandes d’exercice des droits ;
• la suppression ou la restitution des données en fin de contrat ;
• les informations nécessaires aux audits.

Le fournisseur du modèle figure presque toujours parmi ces sous-traitants ultérieurs, et sa localisation déclenche les règles sur les transferts hors UE : l’article 44 subordonne tout transfert vers un pays tiers aux conditions du chapitre V, comme une décision d’adéquation de la Commission européenne ou des clauses types de protection des données. Les accès à distance du support depuis un pays tiers entrent aussi dans l’analyse.

Fuite, injection, données sensibles, journaux : les risques propres

L’ANSSI range les attaques contre l’IA générative en trois familles : manipulation, infection et exfiltration. Un chatbot de service client s’expose surtout à la première et à la dernière.

La fuite par la conversation

Le modèle répond à partir de tout ce qu’il voit : historique, extraits documentaires, données du CRM. Si la recherche documentaire ignore les droits d’accès, un client obtient un extrait de procédure interne, voire une information sur un autre dossier. L’ANSSI demande d’organiser le besoin d’en connaître dès la conception, puis de filtrer en sortie les informations sensibles, coordonnées personnelles ou références de projets, et de limiter la taille des réponses.

L’injection de consignes

Une attaque par injection de consignes détourne le chatbot par le texte qu’il reçoit : un message qui lui ordonne d’oublier ses instructions, ou une consigne cachée dans une page web ou un courriel, à la manière des mails de phishing qui ciblent vos salariés. L’ANSSI recommande de limiter, voire de proscrire, les actions automatiques déclenchées par des entrées non maîtrisées : le chatbot consulte un dossier, mais pour modifier des coordonnées bancaires ou clore un contrat, il passe la main.

Les données sensibles saisies par l’utilisateur

Un adhérent décrit son traitement médical, un client colle son numéro de carte bancaire. La CNIL distingue deux situations : si la collecte de données sensibles est prévisible, le traitement doit entrer dans une exception de l’article 9 du RGPD, comme le consentement explicite ; sinon, une mise en garde avant usage et une purge immédiate ou régulière limitent le risque. Le masquage automatique des numéros avant l’envoi au modèle complète le dispositif.

Les journaux

Côté traçabilité, les journaux de conversation servent l’enquête après incident. L’ANSSI recommande d’y consigner les requêtes, les traitements appliqués avant l’envoi au modèle, les appels aux plugins et aux données additionnelles, les filtres de sortie et les réponses. Ces journaux portent les mêmes données personnelles que les conversations : même durée de conservation, accès restreint, console protégée par une double authentification. Leur fuite reste une violation de données, à notifier à la CNIL si possible sous 72 heures, sauf risque improbable pour les personnes.

Avant de signer : sept questions à poser à l’éditeur

Réunissez DSI, RSSI, DPO et relation client autour d’une même grille, selon la répartition des rôles décrite dans notre dossier sur la cybersécurité en entreprise, et exigez des réponses écrites :

1. Où sont stockés transcriptions, journaux et sauvegardes, et dans quel pays ?
2. Quel modèle traite les messages, chez quel fournisseur, et ce dernier conserve-t-il les requêtes ?
3. Quels sous-traitants ultérieurs, et comment êtes-vous prévenu d’un changement ?
4. La purge s’applique-t-elle aussi au CRM et chez le fournisseur du modèle ?
5. Quels filtres contre l’injection de consignes et la fuite d’informations sensibles ?
6. Qui lit les conversations chez l’éditeur, avec quelle authentification ?
7. Quels motifs déclenchent la reprise humaine, et que reçoit le conseiller ?

Un schéma de flux remis sans attendre vaut plus qu’une plaquette. Prochaine étape : suivez avec l’éditeur pressenti le trajet d’un message réel, du widget au CRM, en notant qui stocke, combien de temps et qui y accède. Ce schéma d’une page devient l’annexe de sécurité du contrat et votre base pour auditer la sécurité du chatbot.

Webotit : des chatbots conçus pour tracer chaque échange

Webotit, éditeur français de chatbots et d’agents IA pour les métiers régulés, conçoit des chatbots de service client qui gardent une trace de chaque conversation, recueillent le consentement des utilisateurs et suivent des règles d’escalade paramétrées selon la politique RGPD du client, du site web jusqu’à l’espace client.

Pour l’audit, l’éditeur consigne et date chaque décision du modèle, avec un export prévu pour les équipes de conformité. Les situations délicates basculent vers un conseiller, qui récupère le fil de l’échange au lieu de tout redemander. Le même socle de connaissances et les mêmes journaux servent sur chaque canal, et le déploiement se fait en SaaS ou sur les serveurs de l’entreprise.

Sécurité d’un chatbot : les questions qui reviennent

Un chatbot d’entreprise peut-il être compatible avec le RGPD ?

Oui, à condition de traiter la conformité comme un réglage du dispositif et non comme une case cochée. Webotit résume ces conditions sur sa page consacrée aux chatbots : un périmètre de données cadré, des sources maîtrisées, des consentements respectés, des échanges tracés et des cas sensibles transférés à un humain. Il reste à l’entreprise, responsable du traitement, de documenter la finalité, la base légale et la durée de conservation, puis de signer avec l’éditeur un contrat conforme à l’article 28.

Où sont stockées les conversations d’un chatbot ?

Rarement à un seul endroit. Le navigateur garde l’historique de la session, les serveurs de l’éditeur conservent les transcriptions et les journaux, le fournisseur du modèle de langage reçoit chaque message pour produire la réponse, et le CRM connecté enregistre souvent un résumé dans la fiche client. Chacun de ces lieux a sa propre durée de conservation et ses propres accès. Demandez à l’éditeur un schéma des flux qui précise, pour chaque étape, le pays d’hébergement et la règle de purge.

Faut-il prévenir l’utilisateur qu’il parle à un robot ?

Oui. Le règlement européen sur l’IA impose que les personnes soient informées qu’elles interagissent avec une machine, et la Commission européenne situe l’entrée en application de ces règles de transparence en août 2026. Le RGPD exige de son côté une information claire sur le responsable du traitement, les finalités, la durée de conservation et les droits. Une mention visible à l’ouverture de la fenêtre de discussion, complétée par un renvoi vers la politique de confidentialité, répond aux deux textes.

Les conversations peuvent-elles servir à entraîner le modèle ?

Techniquement oui, et c’est précisément ce que le contrat doit trancher. L’ANSSI rappelle que les requêtes et les réponses servent parfois à réentraîner un modèle, et recommande de proscrire le réentraînement en production. Exigez une clause écrite qui exclut toute réutilisation des échanges par l’éditeur comme par le fournisseur du modèle, sauf accord exprès de votre part. Vérifiez aussi le sort des conversations déjà annotées par les équipes de l’éditeur pour améliorer les réponses.