Le RGPD d’un chatbot dépend du trajet réel de ses données

Une conversation effacée peut rester présente hors de l’interface

Le signal de risque apparaît lorsqu’une donnée saisie dans le chatbot reste accessible après la réponse. Elle peut avoir été reprise dans le CRM, inscrite dans des journaux, conservée dans une sauvegarde ou copiée par un sous-traitant. Un effacement limité à l’interface laisse alors subsister des éléments ailleurs dans la chaîne. La question utile devient concrète : où cette donnée va-t-elle, pour quelle finalité et qui peut encore agir sur elle ?

Le relevé commence par le cas d’usage précis : sorties attendues, contexte et usages exclus. Cette délimitation permet d’écarter les données sans rapport avec la réponse promise. Chaque donnée est ensuite reliée à sa finalité, à son emplacement et à la règle qui décidera de son sort. Une information utile pour répondre à une demande n’est pas, par ce seul fait, réutilisable pour un autre usage.

Le parcours ne s’arrête pas au stockage principal. Pour chaque composant, le relevé nomme l’acteur capable de traiter une demande d’accès, de rectification, d’opposition ou d’effacement. Il vérifie aussi ce que le contrat du fournisseur prévoit pour la durée, la sécurité, la restitution, les incidents et le sort des copies en fin de prestation. Si l’un de ces maillons ne peut pas être relié à une action effective, la portée d’une demande d’effacement demeure incertaine et appelle une validation juridique.

Le RGPD exige que les données soient adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité.^[1] Cette règle transforme la carte technique en outil de décision : chaque donnée admise doit avoir une raison, chaque destination une fonction et chaque conservation une sortie. Le registre doit refléter les traitements réels, avec leurs sous-traitants et leurs durées, plutôt qu’une représentation simplifiée de l’interface.^[2]

La finalité écarte les données simplement utiles

Une finalité exploitable est déterminée, explicite et légitime dès la définition du projet.^[3] Dans l’exemple méthodologique de l’article, la formule « répondre aux clients » n’est pas retenue pour décider quelles informations un assistant peut recevoir. La décision précise la sortie attendue, les situations admises, celles qui sont exclues et ce que l’outil ne doit jamais transformer en dossier.

Le périmètre fonctionnel sert précisément à nommer les sorties, le contexte d’usage et les informations étrangères au cas principal.^[4] Cette étape réduit la tentation de tout conserver au motif qu’une donnée pourrait être utile plus tard. La pertinence s’apprécie au regard de l’objectif effectivement poursuivi.^[5] La finalité borne ainsi les données recevables et la durée pendant laquelle leur présence reste justifiable.^[6]

Le périmètre peut alors être borné aux données nécessaires à la sortie promise ; cette nécessité n’autorise pas, par elle-même, la collecte ou la conservation. La durée envisagée reste liée à la finalité documentée et soumise aux validations applicables. Le relevé documente les composants et acteurs destinataires avant toute transmission ; cette inscription ne vaut pas autorisation de transfert, qui reste soumis aux rôles, contrats et validations applicables.

La fiche de décision qui relie le cas d’usage aux principes vérifiés.

La durée se décide emplacement par emplacement

La conversation, l’extrait transféré au CRM, le journal et la sauvegarde ne remplissent pas la même fonction. Un réglage unique ne peut donc être retenu sans vérifier qu’il correspond à la finalité de chaque emplacement. La CNIL relie la conservation des conversations à leur finalité et envisage leur effacement dès la fin de l’échange lorsque leur maintien n’est pas nécessaire.^[7]

La bonne règle nomme un point de départ et un événement de sortie. Elle précise aussi qui exécute l’action, comment une exception est autorisée et quelle trace permet de vérifier le résultat. Une durée inscrite dans un document sans mécanisme d’exécution reste une intention.

Les sauvegardes demandent une règle intelligible pour le décideur. Le document indique leur cycle, les restrictions d’accès et le comportement prévu après une restauration. Il doit empêcher qu’un élément retiré des systèmes actifs redevienne exploitable sans contrôle. Si la suppression immédiate d’une copie technique est impossible, cette limite et son traitement doivent être explicités puis validés juridiquement.

Le fournisseur ajoute des responsabilités à documenter

La CNIL indique que le rôle juridique du fournisseur doit être apprécié au cas par cas.^[8] Celui-ci peut héberger les conversations, produire des journaux, solliciter d’autres prestataires ou administrer une partie de l’infrastructure. Pour instruire l’appréciation, la grille documente les opérations effectivement réalisées et signale les ambiguïtés pour validation juridique.

Le contrat de sous-traitance doit notamment définir l’objet, la durée, la finalité, les obligations des parties et la sécurité du traitement.^[9] Pour la carte, ces exigences deviennent des questions vérifiables : où se trouvent les données, qui peut y accéder, comment un incident remonte-t-il, quelles instructions peuvent être exécutées et que deviennent les copies à la sortie ?

À la fin de la prestation, le responsable du traitement peut choisir que le sous-traitant supprime ou restitue les données et détruise les copies existantes, sauf si le droit de l’Union ou d’un État membre impose leur conservation.^[10] Cette capacité doit être compatible avec l’architecture retenue. Un export inutilisable, une suppression invérifiable ou une chaîne de prestataires inconnue rend la sortie fragile.

Dans un cas de suivi de commande, par exemple, le relevé distingue le numéro de commande et l’adresse électronique nécessaires pour retrouver le dossier du message libre, qui peut contenir des informations étrangères à la demande. Il nomme ensuite chaque destination, l’acteur, la donnée transmise et le motif. Une transmission au CRM ou à un sous-traitant est distinguée d’un transfert vers un pays tiers ou une organisation internationale ; dans ce second cas, le registre documente aussi les garanties éventuelles^[2]. Le relevé ne formule aucune conclusion juridique que les preuves disponibles ne permettent pas d’établir. Lorsque ces choix conditionnent l’architecture, un cadrage d’assistant conversationnel adapté aux contraintes réelles devient la suite logique avant de figer la solution.

Un droit reste théorique si une copie échappe au parcours

Le parcours représente l’accès, la rectification, l’opposition et l’effacement comme des opérations suivies de bout en bout afin de préparer leur mise en œuvre. Cette représentation constitue une cartographie, non une définition de l’obligation juridique applicable. Le point d’entrée peut être le support, un formulaire ou un autre canal validé. Il faut alors retrouver les éléments concernés, atteindre les détenteurs autorisés et documenter l’issue.

Une grille opérationnelle reste à soumettre à validation juridique : pour l’accès, recenser les emplacements interrogeables ; pour la rectification, localiser les reprises de la valeur erronée ; pour l’opposition, distinguer les usages concernés ; pour l’effacement, documenter le traitement prévu pour les données actives, journaux, sauvegardes et systèmes des sous-traitants. Cette grille sert à préparer l’exécution ; la portée juridique de chaque droit reste à déterminer par les personnes compétentes.

1. 01

   Recevoir la demande

   Le canal autorisé transmet les éléments nécessaires à son traitement.

2. 02

   Vérifier la portée

   L’acteur compétent identifie la personne, la donnée et l’action demandée.

3. 03

   Rechercher les emplacements

   La carte désigne les systèmes internes et fournisseurs susceptibles de détenir une copie.

4. 04

   Exécuter les actions

   Chaque responsable applique la rectification, l’opposition, l’accès ou la suppression attendue.

5. 05

   Contrôler les dépendances

   Les reprises dans les dossiers, journaux et copies techniques suivent leur règle documentée.

6. 06

   Consigner l’issue

   Le résultat, les limites et les validations requises deviennent vérifiables.

Il faut aussi prévoir les échecs. Un identifiant peut ne pas permettre de retrouver une conversation. Une donnée peut avoir été détachée de son échange d’origine dans le CRM. Un fournisseur peut exiger une procédure spécifique. Ces obstacles doivent être découverts avant la première demande réelle, puis attribués à un responsable et couverts par un test.

Ce tableau relie chaque demande à la capacité technique qui conditionne son exécution.

La présence d’une sauvegarde ou d’un journal ne permet pas de conclure seule à la conduite juridique appropriée. Le relevé décrit le mécanisme, ses limites et l’action techniquement possible. La décision juridique intervient lorsque la qualification, la portée du droit ou une exception reste incertaine. Cette séparation évite de masquer une impossibilité technique derrière une formule de conformité.

La carte fait du déploiement une décision vérifiable

Un test simple consiste à tracer une donnée depuis sa saisie jusqu’à sa suppression ou son transfert. À chaque étape, il faut pouvoir répondre à cinq questions concrètes. Quelle finalité autorise sa présence ? Dans quel composant se trouve-t-elle ? Qui peut agir sur elle ? Quel événement décide de sa sortie ? Comment une demande de droit atteint-elle cet emplacement ?

Ce test peut commencer avec une conversation représentative du cas d’usage, sans prétendre couvrir par analogie toutes les situations. Il faut ensuite vérifier les variantes qui changent réellement le parcours : reprise dans un dossier, contenu non pertinent, intervention d’un fournisseur, conservation technique ou transfert. Une branche inconnue devient une condition à lever avant le déploiement.

La décision d’achat s’en trouve clarifiée. Une solution séduisante à l’écran reste inadaptée si elle ne permet pas d’identifier les destinations, d’appliquer les durées retenues ou de faire traiter la demande par les fournisseurs concernés. À l’inverse, une architecture documentable donne des critères de comparaison précis : capacité d’export, suppression, gestion des journaux, maîtrise des sous-traitants et procédure de sortie.

Ce relevé n’établit pas à lui seul la conformité juridique. Il produit le support factuel nécessaire pour arbitrer, contractualiser et signaler les points qui exigent une validation. La raison d’un échange de cadrage apparaît lorsque le cas d’usage reste utile, alors que le trajet des données, les responsabilités ou les conditions de sortie demeurent indécidables.

La décision de déployer reste en attente tant qu’une branche du trajet ne peut pas être attribuée et vérifiée.