Un chatbot ne demande presque rien, et reçoit beaucoup. C'est cette asymétrie qui rend la mise en conformité moins évidente qu'un formulaire classique.
Point 1 : identifier ce qui est réellement collecté
Un formulaire collecte les champs qu'il affiche. Une conversation collecte tout ce que l'utilisateur écrit, y compris ce que personne ne lui a demandé.
Commencez par lire cent conversations réelles, ou celles d'un outil comparable si le vôtre n'est pas encore ouvert. Vous y trouverez presque toujours des numéros de commande, des adresses, des numéros de téléphone, et régulièrement des éléments de santé ou de situation familiale glissés dans une explication.
Cette lecture change la nature du dossier. Un bot qui reçoit des données de santé, même sans les solliciter, ne relève pas du même régime qu'un bot qui affiche des horaires.
Point 2 : nommer la finalité, et une seule
La finalité doit être précise et déterminée avant la collecte. Répondre aux demandes des clients est une finalité. Améliorer nos services n'en est pas une, elle est trop vague pour fonder quoi que ce soit.
Le point sensible arrive ensuite : si vous comptez réutiliser les conversations pour entraîner ou affiner un modèle, c'est une seconde finalité, distincte de la première. Elle doit être identifiée, justifiée et portée à la connaissance des personnes. La Commission nationale de l'informatique et des libertés a publié des fiches pratiques consacrées à cette question, qui traitent notamment de la définition de la finalité et du choix de la base légale lors du développement d'un système d'intelligence artificielle.
Point 3 : choisir la base légale et savoir la défendre
Quatre bases sont plausibles selon le cas, et le choix n'est pas cosmétique : il détermine les droits des personnes.
L'exécution du contrat couvre le suivi d'une commande en cours. L'intérêt légitime couvre l'assistance générale, à condition d'avoir mené la mise en balance et de pouvoir la montrer. Le consentement s'impose pour les usages qui dépassent le service attendu, la prospection par exemple. L'obligation légale ne concerne que des cas particuliers.
Un projet qui n'a pas tranché ce point avant l'ouverture le tranchera dans l'urgence après une réclamation, dans de moins bonnes conditions.
Point 4 : informer au bon endroit
L'information doit être accessible au moment de la collecte, donc dans la fenêtre de conversation, pas seulement dans une politique de confidentialité en pied de page.
Deux éléments doivent y figurer. Le fait que la conversation est enregistrée et pourquoi. Le fait que l'interlocuteur est un programme : depuis le 2 août 2026, le règlement européen sur l'intelligence artificielle prévoit que les personnes soient informées lorsqu'elles interagissent avec un système d'intelligence artificielle de ce type.
Un lien vers la politique complète reste nécessaire, mais il ne remplace pas ces deux phrases.
Point 5 : fixer une durée de conservation défendable
La durée doit être justifiée par la finalité, ce qui exclut la conservation illimitée par confort.
Deux durées valent mieux qu'une. Une durée courte pour la conversation complète, le temps de traiter la demande et d'éventuelles suites. Une durée plus longue pour des données agrégées et non identifiantes, si vous en avez besoin pour mesurer la qualité.
Vérifiez surtout que la suppression fonctionne réellement, y compris dans les sauvegardes et chez le prestataire. Une durée annoncée mais non appliquée est plus risquée qu'une durée longue et assumée.
Point 6 : décider si une analyse d'impact s'impose
Elle n'est pas systématique. Elle le devient quand le traitement présente un risque élevé pour les droits des personnes, ce qui arrive plus souvent qu'on ne le croit avec un bot : croisement de données, traitement à grande échelle, données sensibles reçues même involontairement, personnes vulnérables.
Menez-la avant l'ouverture, pas après. Elle a une vertu pratique au-delà de la conformité : elle force à écrire ce que le bot fait des données, et cette description manque dans la plupart des projets. Elle sert ensuite de base au registre des traitements et aux réponses à donner en cas de demande d'accès.
Le cas particulier des bots génératifs
Un bot qui formule ses réponses avec un modèle de langue ajoute deux difficultés au dossier.
La première tient au transfert vers le fournisseur du modèle. Chaque question part chez un tiers, souvent avec un extrait de vos documents. Ce tiers est un sous-traitant au sens du règlement, et sa localisation ainsi que ses engagements doivent figurer au contrat. Demandez explicitement si les données transmises servent à entraîner le modèle, et vérifiez que le refus est activé par défaut plutôt que disponible sur demande.
La seconde tient à la restitution involontaire. Un modèle peut reproduire un élément présent dans les documents qu'on lui a fournis, y compris un nom ou un dossier qui n'avait rien à faire dans le corpus. Le contrôle se fait en amont, sur ce que l'on verse au corpus, pas en aval sur ce que le modèle en dit.
Les droits des personnes, en pratique
Trois demandes arriveront tôt ou tard, et il vaut mieux savoir y répondre avant qu'après.
L'accès : une personne demande la copie de ses échanges. Pouvez-vous retrouver toutes ses conversations si elle n'était pas identifiée au moment où elle a écrit ? Beaucoup de bots ne conservent qu'un identifiant technique, ce qui rend la recherche impossible et complique la réponse.
L'effacement : la suppression doit atteindre l'outil de conversation, l'outil de ticket où la conversation a peut-être été recopiée, et les sauvegardes. Le point de recopie est celui qu'on oublie.
L'opposition : une personne refuse que ses échanges servent à améliorer le service. Ce refus doit être techniquement applicable, ce qui suppose que l'usage d'amélioration ait été isolé dès la conception.
Commentaires
No comments yet