Chatbot IA et RGPD : bien planifier les flux de données, les mentions et la suppression

Un formulaire de contact comporte des champs obligatoires, un bouton d’envoi et un moment clair où les données quittent le navigateur. Une fenêtre de chat n’a rien de tout cela. Les visiteurs écrivent comme ils parlent : « Je suis Madame Meier, mon tuyau de chauffage fuit depuis hier, rappelez-moi à ce numéro. » Une seule phrase contient un nom, un numéro de téléphone et une demande liée au lieu de résidence.

Dans ce scénario, une entreprise artisanale a construit un chatbot sous forme de prototype. Il répond aux questions sur les prestations et recueille les demandes de rendez-vous. Sur le plan fonctionnel, il convainc, mais à la question de savoir où se trouvent les conversations, on n’obtient qu’un haussement d’épaules. Le prestataire est quelque part, le modèle vient d’une autre société encore, et la politique de confidentialité ne mentionne pas le chat.

Ce point de départ est courant. Il ne résulte pas d’une négligence, mais du fait qu’en phase de développement un chatbot apparaît comme une fonctionnalité et seulement plus tard comme un traitement de données. L’étude montre comment inverser cet ordre. Elle constitue une orientation pour la planification et pour les échanges avec votre conseil en protection des données, expressément pas un conseil juridique et pas un substitut à l’examen de votre cas particulier.

La première question est : les visiteurs savent-ils qu’ils écrivent à une machine ? Un prénom aimable et une photo suffisent pour qu’on suppose une collaboratrice. La deuxième : où vont les saisies ? Entre le navigateur et la réponse, il y a souvent trois étapes, chacune avec ses propres serveurs et ses propres règles.

La troisième question concerne la durée. De nombreux outils de chat enregistrent les historiques par défaut et sans limite, car c’est pratique pour les analyses. Sans décision délibérée, il se constitue ainsi une archive de déclarations personnelles que personne n’a demandée. La quatrième question est la plus gênante : que faites-vous si quelqu’un veut faire supprimer ses données et que vous ne savez pas dans quelle conversation elles se trouvent ?

À cela s’ajoute un type d’erreur plus fréquent au quotidien que la grande fuite de données : par souci d’être serviable, le bot demande plus que nécessaire. Qui s’informe d’un horaire d’ouverture n’a pas à donner d’adresse. Qui laisse une demande de rappel n’a pas besoin de décrire ses antécédents médicaux, ce qui peut vite arriver dans les cabinets. Plus la saisie est ouverte, plus ce qui arrive est dispersé.

Avant de parler de contrats, une image simple du flux de données est utile. Un message commence dans le navigateur du visiteur, va au serveur du fournisseur du chatbot, de là à l’interface d’un modèle de langage, puis revient. Pour les demandes de rendez-vous ou de rappel, une quatrième étape s’ajoute : un agenda, un CRM ou une boîte de réception vers lesquels les données sont transmises.

Chaque étape appelle les mêmes questions. Qui l’exploite, dans quel pays se trouvent les serveurs, le message est-il enregistré, est-il utilisé pour améliorer des modèles ? La dernière question est particulièrement importante, car les fournisseurs diffèrent sur ce point. Pour les interfaces professionnelles, de nombreux fournisseurs excluent contractuellement l’utilisation à des fins d’entraînement ; pour les offres grand public, c’est souvent différent. Cela doit ressortir des documents contractuels, pas d’une supposition.

Un exemple montre avec quelle facilité des étapes sont oubliées. Le chat lui-même fonctionne chez un fournisseur situé dans l’UE, mais la notification d’un nouveau rappel est envoyée par e-mail via un autre service, qui contient le message mot pour mot. Soudain, la même phrase se trouve à deux endroits, avec deux durées différentes. Ces chemins annexes passent inaperçus quand on ne considère que le système de chat.

Une feuille de papier suffit pour cet état des lieux. Nous dessinons les étapes, ajoutons pour chacune l’exploitant, l’emplacement, le stockage et la finalité, et marquons où des données personnelles apparaissent réellement. On constate souvent qu’un outil voit plus que prévu, par exemple un script d’analyse qui lit le contenu ou un journal qui stocke les messages en clair.

La solution de facilité serait de se fier à la page de confidentialité du fournisseur du chatbot. Mais elle décrit son point de vue, pas le vôtre. Vous êtes responsable du traitement sur votre site web, même si vous achetez la technologie. Le fournisseur est en règle générale un prestataire qui traite des données pour votre compte, et, selon des principes généralement connus, un contrat de sous-traitance est alors nécessaire.

Nous procéderions donc en trois étapes. Premièrement, clarifier les rôles : qui est le responsable du traitement, qui est le sous-traitant, et y a-t-il des sous-traitants ultérieurs, par exemple l’exploitant du modèle ? Deuxièmement, vérifier si le contrat de sous-traitance couvre la chaîne réelle, y compris l’emplacement et les sous-traitants ultérieurs. Troisièmement, évaluer si un transfert vers des pays hors de l’UE a lieu et sur quelle base.

Il existe des alternatives. Un modèle exploité en propre garde les données dans votre propre centre de données, mais exige exploitation, mises à jour et sécurité de votre côté, ce qui est rarement rentable pour de petites entreprises. Un fournisseur avec des serveurs dans l’UE réduit les questions sur les transferts, mais n’est pas automatiquement conforme à la protection des données. Le choix est un arbitrage entre effort, qualité des réponses et contrôle, et il devrait être justifié par écrit afin d’être traçable plus tard.

Une troisième voie consiste à ne pas laisser les données se constituer. Moins le bot demande, plus chaque question sur les contrats et la durée de conservation se réduit. Cette attitude de minimisation des données est un principe généralement connu et le levier le plus efficace de tout le concept.

La mention de l’IA doit précéder le premier mot. À titre d’orientation générale : celui qui s’adresse à un système d’IA devrait pouvoir le reconnaître, au plus tard au début de la conversation. Le règlement européen sur l’IA reprend cette idée avec des obligations de transparence. Quelles obligations s’appliquent concrètement à votre chatbot et à partir de quand, vous le clarifiez avec votre conseil juridique. Sur le plan technique, la mention est de toute façon judicieuse, car elle fixe des attentes réalistes.

Le message d’accueil peut remplir les deux fonctions : « Je suis l’assistant numérique de [entreprise] et une IA. Je réponds aux questions sur les prestations et les rendez-vous. Merci de ne pas saisir ici d’informations sensibles comme des données de santé, des numéros de compte ou des mots de passe. » Deux phrases, un lien vers l’information sur la protection des données. C’est plus court que n’importe quel mur de pop-ups et plus susceptible d’être lu.

La saisie elle-même peut être guidée. Au lieu d’un champ de texte ouvert pour tout, le bot conduit pas à pas : choisir la demande, indiquer l’horaire souhaité, ne demander les coordonnées qu’à la fin, dans des champs dédiés. Les champs structurés ont un avantage que le texte libre n’offre pas. On peut les valider, les enregistrer séparément et les supprimer de façon ciblée, alors qu’un nom noyé au milieu d’un paragraphe est presque introuvable.

Pour les cabinets et les autres domaines manipulant des informations particulièrement sensibles, une ligne plus stricte s’applique. Le bot devrait s’y limiter visiblement aux questions d’organisation et, lorsque des plaintes ou des symptômes sont décrits, renvoyer aimablement vers le téléphone ou un rendez-vous. C’est moins une question de technique que de délimitation des tâches, et cela doit figurer dans les instructions du bot avant le lancement.

La mise en œuvre technique commence là où l’on économise souvent : la configuration de l’historique. Nous vérifions si le fournisseur propose une durée de conservation réglable, si les historiques peuvent être supprimés automatiquement et si des conversations individuelles peuvent être retrouvées par un identifiant. Si l’une de ces fonctions manque, ce n’est pas un détail, mais un critère de choix du fournisseur.

Le widget de chat n’est chargé qu’après consentement lorsqu’il établit des connexions avec les serveurs du fournisseur et transmet par exemple l’adresse IP. Savoir si un consentement est nécessaire ou si une autre base juridique suffit dépend de l’architecture et relève de l’examen juridique. Techniquement, cela signifie que le chat ne se charge pas automatiquement à l’ouverture de la page, mais derrière un clic ou une demande. Effet secondaire : le temps de chargement diminue.

Les journaux méritent une attention particulière. En plus de l’historique, les serveurs web, la surveillance des erreurs et les outils d’analyse conservent souvent des données dans lesquelles peuvent apparaître des messages ou des identifiants. Nous vérifions si des contenus du chat apparaissent en clair dans les messages d’erreur, les transferts par e-mail ou les webhooks, et nous les raccourcissons ou les masquons lorsque c’est possible. Les transmissions vers l’agenda ou le CRM ne transportent, elles aussi, que les champs nécessaires.

La suppression nécessite une voie définie. En pratique, un identifiant par conversation s’est avéré efficace, transmis lors du passage au système en aval. Ainsi, pour une demande, la conversation dans le système de chat et l’entrée correspondante dans l’agenda ou le CRM peuvent être retrouvées. On définit en outre des délais automatiques à l’issue desquels les historiques disparaissent, même si personne n’y pense.

Le cas particulier le plus fréquent est la révélation spontanée. Un visiteur décrit longuement sa maladie, sa séparation d’avec son partenaire ou ses dettes, alors que la question portait seulement sur un rendez-vous. Le bot ne peut pas l’empêcher, mais il peut réagir calmement : confirmer brièvement, ne pas poser de questions complémentaires, renvoyer vers le bon canal de contact. Un bot qui relance avec zèle aggrave la situation.

Une particularité concerne les conversations que le bot interrompt ou ne comprend pas. Les visiteurs répètent alors leurs informations, souvent plus en détail et de façon plus personnelle qu’avant. Un passage de relais précoce et aimable à un humain aide ici, avant que quelqu’un explique sa situation pour la troisième fois. C’est un bon service et, en même temps, de la minimisation des données.

Le deuxième cas concerne les mineurs et les tiers. Celui qui demande un rendez-vous pour sa mère transmet les données d’une autre personne. Dans de telles conversations, le bot devrait ne demander que le strict nécessaire et ne pas déduire de l’historique d’autres personnes. Une vérification d’âge généralisée n’est pas faisable de manière fiable dans un chat ; ce qui aide surtout, c’est une offre qui s’adresse manifestement à des adultes.

Un autre cas concerne les pièces jointes. Dès que les visiteurs peuvent téléverser des photos ou des documents, par exemple une photo du sinistre ou un courrier, le volume de données augmente considérablement, et l’on voit souvent sur les images des personnes, des plaques d’immatriculation ou des adresses. Nous renoncerions aux téléversements dans un premier temps et renverrions plutôt vers une voie distincte, avec sa propre information et une courte conservation.

Troisièmement, la demande d’accès ou de suppression. Lorsque quelqu’un se manifeste, il veut savoir ce qui est enregistré à son sujet. Sans identifiant ni coordonnées dans la conversation, on ne peut y répondre, et ce n’est pas une erreur. Il ne faut pas collecter après coup des caractéristiques uniquement pour pouvoir rattacher une conversation. La demande exige en outre une vérification d’identité, pour que des personnes non autorisées ne réclament pas d’historiques.

Un quatrième cas est l’injection de prompt, c’est-à-dire la tentative d’amener le bot, par des saisies, à divulguer des instructions internes ou des données de tiers. Cela devient pertinent pour la protection des données lorsque le bot a accès à des données clients. C’est pourquoi, dans le doute, il n’en reçoit aucune. La base de connaissances et les données de conversation restent séparées, et le bot ne voit jamais plus que la conversation en cours.

Un concept rigoureux réduit les risques, il ne les supprime pas. Il rend les décisions traçables : vous pouvez expliquer quelles données sont collectées, pourquoi, où elles se trouvent et quand elles disparaissent. Si une construction concrète est juridiquement suffisante, c’est en définitive votre conseil en protection des données ou votre délégué à la protection des données qui en décide. Un concept de ce type ne peut pas garantir la conformité juridique, et nous n’en donnons pas non plus.

On peut mesurer l’avancement à l’aide d’éléments vérifiables. Existe-t-il un contrat pour chaque prestataire impliqué ? La politique de confidentialité correspond-elle au traitement réel ? Les délais de suppression s’exécutent-ils automatiquement, et peut-on le montrer par sondage sur une conversation de test ? Combien de conversations contiennent des informations que le bot n’aurait pas dû demander ? Ce dernier point peut s’observer sur un échantillon d’historiques anonymisés pendant quelques semaines.

Pour l’activité aussi, il y a un bénéfice qui ne se chiffre pas mais se décrit. Les visiteurs qui savent à l’avance à qui ils parlent et ce qu’il advient de leurs informations abandonnent probablement moins souvent la conversation. C’est une attente, pas une mesure, et les taux d’abandon et les questions dans votre chat, comparés avant et après l’adaptation, montreront si elle se vérifie. Les chiffres correspondants devraient provenir de votre propre entreprise.

Un autre point de contrôle est la cohérence. Si la politique de confidentialité affirme une durée de conservation que le système ne respecte pas, c’est pire qu’un délai long mais honnête. Nous rapprochons donc le texte et la configuration, pas seulement une fois avant le lancement, mais à chaque modification du chat.

On ne peut pas garantir qu’il n’arrivera jamais rien d’inattendu. Les visiteurs saisissent ce qu’ils veulent, les fournisseurs modifient leurs conditions, les modèles reçoivent de nouvelles fonctions. C’est pourquoi le concept prévoit un contrôle régulier, par exemple deux fois par an et à chaque changement de fournisseur ou de modèle.

Premièrement : la protection des données pour un chatbot est d’abord une tâche de conception. Celui qui construit les dialogues de manière à générer peu d’informations personnelles a moins à protéger, à expliquer et à supprimer. Cela réduit aussi l’effort pour toutes les étapes ultérieures. Deuxièmement : la documentation devrait être établie parallèlement à la configuration. Une note avec la date, qui a réglé quoi et pourquoi, vaut plus tard davantage que n’importe quelle reconstitution a posteriori.

Troisièmement : les textes de mention sont des textes de produit. Ils devraient être rédigés dans le langage de l’entreprise, courts et concrets, sans jargon juridique dans la fenêtre de chat. L’information détaillée relève de la politique de confidentialité et y est reliée par un lien. Nous testons volontiers les textes auprès de personnes qui ne connaissent pas le projet et leur demandons ce qu’elles pensent qu’il advient de leurs saisies.

Quatrièmement : les collaborateurs en font partie. Celui qui traite les rappels issus du chat devrait savoir combien de temps il peut conserver les données, où elles n’ont pas leur place et comment transmettre une demande de suppression. Une voie de suppression que personne ne connaît ne fonctionne que sur le papier. Cinquièmement : un chatbot évolue avec sa base de connaissances. Chaque nouvelle fonction, comme la prise de rendez-vous ou le téléversement de documents, exige une brève réévaluation du flux de données.

Pour finir, une erreur courante : plus de mentions ne signifie pas plus de protection. Une bannière que personne ne lit ne remplace pas la minimisation des données, et un consentement ne remplace pas la question de savoir si le traitement est nécessaire. Ce qui est efficace, c’est ce qui réduit le traitement, pas ce qui se contente de l’annoncer.

Un chatbot de site web peut soulager les demandes et aider plus vite les visiteurs. Il traite pour cela des déclarations que les visiteurs saisissent en pensant avoir une conversation. Cette différence avec le formulaire est le cœur de la tâche. Celui qui connaît le trajet des données, a clarifié les rôles et les contrats, met en place la mention de l’IA et fixe des délais de conservation et de suppression a répondu aux questions essentielles avant que quiconque ne les pose.

La prochaine étape est modeste : dessinez par quelles étapes passe un message dans votre chat et notez ce que vous savez de l’emplacement, du stockage et du contrat de chaque étape. Les lacunes sont les sujets pour votre conseil en protection des données. Nous vous aidons volontiers sur le volet technique de cet état des lieux ainsi que pour la rédaction des textes de mention et des dialogues.

Pour être honnête, il faut ajouter : l’appréciation juridique reste entre vos mains et celles de votre conseil. Nous fournissons une technique vérifiable et une documentation qui répond aux questions au lieu d’en soulever de nouvelles. Cela fait gagner du temps à chaque échange ultérieur.

Pour les petites entreprises, l’effort est raisonnable s’il intervient tôt. Un état des lieux du flux de données, un projet de textes de mention et la configuration des délais peuvent être préparés en quelques jours ouvrés. Cela devient coûteux lorsqu’un chat en service, avec des centaines de conversations, doit être remis en ordre après coup. Le calendrier ci-dessous montre un enchaînement possible.