Chatbot et RGPD : obligations de conformité

Un chatbot peut répondre sans recueillir systématiquement un consentement RGPD, mais chaque usage des échanges doit avoir son propre fondement. Répondre à une question, conserver une réclamation, entraîner un modèle et cibler une offre ne sont pas la même finalité. Un cookie strictement nécessaire au dialogue demandé peut être exempté ; un suivi publicitaire associé ne bénéficie pas de cette justification.

Le fait de ne pas demander de nom ne rend pas les échanges anonymes. Un numéro de commande, un texte libre ou un identifiant technique peut permettre de les rattacher à une personne. La bonne unité de travail est donc le parcours du message, et non la seule fenêtre visible du chatbot.

Avant le déploiement, dessinez le parcours d’un message : navigateur, outil de conversation, modèle éventuel, équipe support et archives. Ajoutez les usages secondaires, même s’ils sont activés par défaut chez le prestataire.

Définir les usages et les bases légales

Répondre à une demande, gérer une réclamation, entraîner un modèle et cibler une offre sont des finalités différentes. Les Art. 5(1)(b), 5(1)(c) et 6(1) du RGPD imposent une finalité définie, des données nécessaires et une base légale adaptée. Le contrat peut couvrir ce qui est objectivement nécessaire à son exécution ; l’intérêt légitime exige une analyse propre ; le consentement n’est pas un passage obligé pour toute conversation. RGPD, chapitre II.

Le guide du chat commercial et des coordonnées traite le passage de l’échange anonyme ou pseudonyme à une fiche contact. Pour une réutilisation, examinez séparément l’historique de chatbot destiné au ciblage.

Attendre l’activation pour les traceurs nécessaires

La CNIL distingue le cookie déposé avant l’activation du chatbot de celui nécessaire au service expressément demandé lorsque la personne ouvre la conversation. Dans le second cas, une exemption peut être possible si le traceur sert uniquement au chatbot. Ajouter une finalité publicitaire empêche de justifier l’ensemble du suivi par la seule continuité du dialogue. Conseils CNIL sur les chatbots.

Contrôlez donc trois états : page chargée sans interaction, conversation ouverte et conversation fermée. Relevez les requêtes et les informations stockées dans chacun. Le bandeau de consentement doit piloter les fonctions qui en dépendent réellement.

Pour chaque traceur, demandez au développeur sa fonction et son déclencheur. Si le même cookie maintient la conversation et alimente un profil commercial, séparez les fonctions ou bloquez l’usage non exempté tant qu’aucun accord valable n’a été donné. Cette décision découle du périmètre de l’article 82 de la loi Informatique et Libertés, pas du choix d’une marque de chatbot.

Informer au bon moment, y compris sur l’IA

Affichez avant la saisie une indication claire sur l’outil, l’enregistrement et l’accès à la notice complète. Si une pièce jointe ou une connexion au compte apporte davantage de données, expliquez cette étape lorsqu’elle intervient. Les Art. 13(1) et (2) du RGPD encadrent l’information lors de la collecte. RGPD, chapitre III.

L’Art. 50(1) du règlement sur l’IA, applicable depuis le 2 août 2026, prévoit une obligation de conception pour que les personnes sachent qu’elles interagissent directement avec un système d’IA, sauf si cela est évident dans les circonstances prévues par le texte. La Commission distingue les responsabilités des fournisseurs et des déployeurs : demandez au fournisseur comment l’information est assurée, puis vérifiez votre intégration. FAQ officielle de la Commission sur l’Art. 50.

Une indication proposée pour un assistant de vente pourrait être : « Vous échangez avec notre assistant automatisé utilisant une IA. Il répond à partir de nos fiches produits. Ne transmettez pas de données bancaires ou médicales. Pour une réclamation ou une réponse personnalisée, vous pouvez contacter notre équipe. » Ajoutez l’accès à l’information sur les données et adaptez ce texte aux fonctionnalités réelles. Ne promettez pas l’absence d’enregistrement si des conversations sont conservées.

Gérer le texte libre et la conservation

Un visiteur peut révéler une information de santé sans y avoir été invité. Prévoyez un avertissement adapté et une procédure de purge des données non pertinentes. Si votre service est précisément destiné à recevoir des données sensibles, il faut identifier une condition de l’Art. 9(2) en plus de la base légale. Une case générale n’efface pas cette analyse.

La CNIL distingue les conversations ponctuelles à effacer en fin d’usage des échanges dont la finalité justifie une conservation plus longue, comme une réclamation. Elle ne fixe pas un plafond universel de 48 heures ni une durée unique de deux ans. Recommandations sur les chatbots.

Construisez un calendrier par données : conversation active, dossier support utile, journaux techniques et éventuelle archive probatoire. La clôture d’un dossier doit déclencher la règle correspondante chez vous et chez les prestataires.

Cas pratique : un marchand de vélos prépare son assistant

Exemple hypothétique. Une PME française veut répondre aux questions sur les dimensions et l’entretien des vélos vendus en ligne. Elle choisit de démarrer avec les fiches produits publiques, sans donner au moteur accès aux commandes, aux factures ou aux anciens dossiers clients. Ce périmètre permet d’aider à choisir un modèle sans exposer la totalité du service après-vente.

Une personne demande si un porte-bagages convient à son vélo. Le chatbot utilise la référence du produit et les caractéristiques du catalogue. Il n’a pas besoin de l’identité du propriétaire ni de son adresse. Si la référence manque, il la demande ; il ne cherche pas à identifier le visiteur à partir de sa navigation antérieure.

Le visiteur signale ensuite un défaut sur un article acheté. Le bot propose un transfert vers un conseiller. L’identification et les détails nécessaires à la réclamation passent par le parcours sécurisé du service client. Le moteur général de recommandation n’a pas besoin de recevoir les pièces complètes. Cette séparation évite qu’un document envoyé pour faire jouer une garantie rejoigne une base d’entraînement ou une liste commerciale.

Fiche de décision renseignée

Pour les demandes générales qui ne constituent pas des mesures précontractuelles prises à la demande d’une personne, la PME doit retenir un autre fondement adapté, par exemple un intérêt légitime après analyse. Le tableau décrit un périmètre précis ; il ne qualifie pas tous les messages possibles sur un site.

Attribuer les tâches et vérifier le prestataire

Le responsable du service client valide les questions autorisées et les cas à transférer. Le développeur limite les sources accessibles, vérifie les autorisations et configure les événements techniques. Le référent RGPD examine les finalités, les contrats et les durées. Le fournisseur doit expliquer quelles entités reçoivent le texte, y compris l’éventuel opérateur du modèle et ses prestataires.

Si le fournisseur ne sait pas confirmer comment désactiver un usage secondaire des conversations, la PME ne traite pas ce manque comme une réponse positive. Elle propose une FAQ statique sans lui transmettre de messages, choisit une configuration vérifiable ou un autre prestataire, ou reporte l’ouverture. Un texte libre peut toujours contenir des données personnelles ; une simple promesse commerciale ne remplace pas les engagements et paramètres.

Une connexion au compte client constitue une évolution substantielle du scénario. Pour afficher une commande, le système doit vérifier que la personne a le droit d’y accéder. Connaître un numéro de commande ne doit pas suffire à récupérer les coordonnées d’un autre client. Le contrôle doit être effectué par l’application et ses droits d’accès ; le modèle ne doit pas pouvoir le contourner en reformulant une demande.

Encadrer le fournisseur et les risques

Demandez les conditions d’utilisation des conversations, les sous-traitants, les lieux de traitement, les accès de support et les réglages d’entraînement. Un prestataire peut agir pour votre compte sur certaines opérations et poursuivre des finalités propres sur d’autres. L’Art. 28(3) encadre la sous-traitance ; l’Art. 32(1) impose une sécurité adaptée aux risques. RGPD, chapitre IV.

Pour l’IA générative, vérifiez les réponses et les documents accessibles au système. Une instruction disant de ne pas révéler de données ne remplace pas un contrôle d’accès. La CNIL recommande une gouvernance adaptée aux usages et aux risques de ces outils. FAQ sur l’utilisation de l’IA générative.

Enfin, l’Art. 35(1) rend l’AIPD obligatoire en présence d’un risque élevé. Il n’existe pas de seuil général de 10 000 utilisateurs ni d’obligation automatique pour tout chatbot génératif. Documentez l’analyse et consultez la méthode d’analyse d’impact.

La présence d’un bot ne suffit pas non plus à déclencher l’Art. 22. Celui-ci vise les décisions exclusivement automatisées ayant un effet juridique ou similaire significatif. Dans notre exemple, le bot peut expliquer une procédure de retour ; la PME lui interdit de rejeter automatiquement une réclamation ou de priver un client d’un droit. Si le système décide réellement à la place d’un humain, il faut examiner les conditions et garanties des Art. 22(1) à (4), pas ajouter seulement un bouton « contacter le support » après la décision.

Vérifier les réponses et prévoir l’arrêt en cas d’anomalie

Avant lancement, l’équipe utilise des dialogues fictifs représentant quatre situations : conseil produit ordinaire, question sans réponse dans le catalogue, message contenant une information médicale et tentative d’obtenir le dossier d’un autre client. Conservez pour chaque parcours la réponse attendue, le résultat et les destinataires techniques constatés.

Le parcours ordinaire doit rester dans le catalogue autorisé. La question inconnue doit donner lieu à une limite clairement annoncée et, si nécessaire, à un contact humain, pas à une règle commerciale inventée. L’information médicale non pertinente doit être écartée et purgée selon la procédure prévue. La demande visant le compte d’un tiers doit être bloquée par les droits de l’application.

Si une réponse révèle des données d’un autre client, suspendez l’accès concerné et les fonctions qui en dépendent. Préservez les éléments nécessaires à l’analyse de l’incident, avec des accès limités. Corrigez l’autorisation ou la source documentaire, puis rejouez les parcours avant réactivation. Une instruction supplémentaire adressée au modèle ne suffit pas si le défaut se trouve dans l’accès aux données.

Lorsque l’incident constitue une violation de données, appliquez les Art. 33 et 34 : évaluation du risque, documentation et notifications lorsque leurs conditions sont réunies. Notifiez l’autorité dans les meilleurs délais et, si possible, au plus tard 72 heures après en avoir pris connaissance, sauf violation peu susceptible d’engendrer un risque. Un dépassement doit être motivé. Source : RGPD, chapitre IV.

Après lancement, recommencez ces contrôles lorsque changent le modèle, les documents accessibles ou les intégrations. Le responsable du service doit aussi pouvoir recevoir une demande d’accès ou d’effacement et retrouver les échanges concernés sans multiplier les données d’identification collectées.

Ce qu’il faut retenir

• Cartographiez les finalités et les destinataires au-delà de la fenêtre de chat.
• Vérifiez les traceurs avant et après l’activation du service.
• Prévoyez information, purge des messages non pertinents et durées justifiées.
• Évaluez les usages de l’IA et le risque élevé sans inventer de seuil universel.

FAQ

Un chatbot sans formulaire d’identité est-il anonyme ?

Pas nécessairement. Les messages, identifiants et données techniques peuvent permettre de relier l’échange à une personne.

Le fournisseur peut-il entraîner son modèle avec les conversations ?

Cette utilisation doit être examinée pour elle-même : finalité, rôle, base légale, information et garanties. Le contrat commercial ne suffit pas à la rendre licite.

Peut-on garder toutes les conversations pour améliorer le service ?

Une amélioration générale ne justifie pas une conservation indéfinie. Définissez les données réellement utiles, une durée et les moyens de limiter les informations personnelles.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.