Un client lit les données d'un autre dans votre chatbot : le sinistre RGPD

Le scénario est presque toujours le même, et il ne ressemble pas à une cyberattaque spectaculaire. Pas de hacker, pas de ransomware. Juste un chatbot qui, interrogé par un utilisateur sur « mes dernières commandes », interroge le CRM avec un identifiant mal isolé et renvoie les commandes d'un autre utilisateur : nom, adresse, produits achetés, parfois numéro de téléphone.

La cause est presque toujours une défaillance de cloisonnement dans l'intégration que vous avez construite : un token de session réutilisé, un identifiant client passé en paramètre sans contrôle d'autorisation, un cache partagé entre conversations, ou une requête API qui ne filtre pas sur l'utilisateur authentifié. Le LLM n'y est pour rien. C'est de l'ingénierie d'intégration — votre cœur de métier.

Une variante, plus sournoise encore, mérite d'être citée : la fuite par le contexte du modèle. Certaines architectures conservent en mémoire les échanges précédents pour donner du « contexte » au LLM. Si ce contexte n'est pas purgé entre deux utilisateurs, ou s'il est mutualisé pour des raisons de performance, le modèle peut restituer à un utilisateur un fragment de la conversation d'un autre. Le symptôme est troublant : le bot « se souvient » d'une information qu'il n'aurait jamais dû connaître pour cet utilisateur. Là encore, la cause est architecturale, et elle vous est imputable en tant que concepteur de l'intégration.

Au regard du RGPD, peu importe que ce soit accidentel : il y a eu accès non autorisé à des données personnelles. C'est une violation de données (article 4.12 du RGPD), avec tout le régime qui l'accompagne.

Dès que la violation est découverte, une horloge se met en marche. Le responsable de traitement — votre client — dispose de 72 heures pour notifier la CNIL (article 33 du RGPD), sauf si la violation est improbable d'engendrer un risque pour les personnes. Or une fuite de données d'identité et d'achat entre utilisateurs présente clairement un risque.

Si ce risque est élevé, il faut en plus informer individuellement les personnes concernées (article 34). Imaginez le message à envoyer : « Vos données ont pu être consultées par un autre client via notre assistant. » L'effet réputationnel est immédiat, et votre client vous en tiendra rigueur, car la cause technique vous est imputable.

Le piège : le client panique, la CNIL est notifiée, l'audit démarre — et personne n'a encore chiffré ce que tout cela coûte. Faisons-le.

Prenons un cas réaliste : un chatbot e-commerce, 4 000 utilisateurs exposés sur une fenêtre de 48 h avant correction. Voici comment le coût se construit, hors amende administrative.

On atteint facilement 30 000 à 80 000 € avant même qu'une éventuelle sanction CNIL n'entre en ligne de compte. Pour un consultant freelance ou une petite structure, c'est un montant qui peut emporter l'entreprise. Et la plus grande part de cette facture, votre client cherchera à vous la faire supporter.

Notez que ces chiffres ne tiennent pas compte de l'éventuelle amende administrative. Le RGPD prévoit des sanctions pouvant atteindre, pour les manquements les plus graves, 20 millions d'euros ou 4 % du chiffre d'affaires mondial. Dans la pratique, une violation accidentelle, rapidement notifiée et corrigée, donne rarement lieu à une sanction maximale. Mais la CNIL apprécie notamment la sécurité mise en place en amont. Un cloisonnement absent, c'est exactement le type de manquement de sécurité qui transforme un incident en faute. Et cette appréciation rejaillit sur vous : si l'enquête établit que la cause est une intégration mal sécurisée, le client argumentera que la défaillance technique vous est entièrement imputable.

La RC Pro couvre votre responsabilité pour le dommage immatériel causé au client par votre faute de conception. C'est nécessaire, mais ce n'est pas toute l'histoire. Un sinistre de violation de données génère des frais de gestion de crise qui ne sont pas, par nature, un dommage causé à un tiers : audit forensique, notification, communication, hotline.

C'est précisément le rôle de l'option Cyber adossée à votre contrat. Elle prend en charge la gestion de l'incident lui-même : la mobilisation d'experts forensiques, l'accompagnement réglementaire RGPD, et les frais de notification. Pour un consultant chatbot IA qui branche en permanence des assistants sur des CRM et bases clients (Zendesk, HubSpot, Salesforce), c'est la couverture qui transforme un sinistre potentiellement mortel en incident gérable. Vous trouverez le détail sur la page assurance cyber.

Un point que beaucoup de consultants ignorent : en branchant un chatbot sur les données clients de votre donneur d'ordre, vous devenez souvent sous-traitant au sens de l'article 28 du RGPD. Ce statut n'est pas anodin. Il impose la signature d'un contrat de sous-traitance (ou DPA) qui définit vos obligations de sécurité, et il vous expose directement : depuis le RGPD, un sous-traitant qui manque à ses obligations de sécurité peut voir sa responsabilité engagée, y compris par l'autorité de contrôle.

Autrement dit, vous n'êtes pas un simple prestataire technique invisible derrière votre client. Vous êtes un maillon identifié de la chaîne de traitement, avec des devoirs propres. Cela renforce l'enjeu de votre couverture : un sinistre de violation de données peut vous viser à un double titre — comme concepteur fautif vis-à-vis de votre client (terrain RC Pro) et comme sous-traitant défaillant vis-à-vis du RGPD (terrain Cyber et accompagnement réglementaire). Vérifiez systématiquement qu'un DPA encadre la mission et que vos obligations y sont réalistes au regard de ce que vous livrez réellement.

Ce sinistre est presque toujours évitable. Quelques principes d'ingénierie, intégrés dès la conception, suppriment l'essentiel du risque :

• Cloisonnement strict par utilisateur authentifié : toute requête vers le CRM doit filtrer sur l'identité vérifiée de l'utilisateur courant, jamais sur un identifiant passé librement dans la conversation.
• Pas d'identifiant client dans le contexte du LLM : l'autorisation se gère côté backend, hors de portée du prompt, pour éviter qu'un utilisateur ne manipule le bot pour usurper une identité.
• Isolation des sessions et des caches : aucune donnée d'une conversation ne doit fuiter vers une autre.
• Tests d'accès croisé : simulez délibérément un utilisateur tentant de lire les données d'un autre, avant la mise en production.
• Minimisation : ne faites remonter dans le chatbot que les données strictement nécessaires à la réponse.

Documentez ces contrôles. En cas de litige, prouver que vous aviez mis en place le cloisonnement et testé l'accès croisé déplace radicalement la discussion sur la responsabilité.