Tous les articles

Chatbot e-commerce et RGPD : les questions à poser avant de signer

Un chatbot traite des données personnelles pour votre compte. Ce que ça implique juridiquement, et les six questions qui départagent les fournisseurs.

Robin PapillonCofondateur et CTO de Selvren9 min de lecture

Un chatbot posé sur une boutique n'est pas un widget d'affichage. Dès qu'un visiteur écrit « je n'ai pas reçu ma commande 48213 » ou décrit sa situation personnelle, vous traitez des données personnelles, et vous les faites traiter par un tiers.

Ce billet ne remplace pas un conseil juridique. Il liste ce qu'un commerçant doit regarder, et les questions qui départagent réellement deux fournisseurs.

Qui est responsable de quoi

La répartition est simple et souvent mal comprise.

Vous décidez pourquoi le chatbot existe et ce qu'il fait. Vous êtes donc responsable de traitement. Le fournisseur agit sur vos instructions : il est sous-traitant. S'il fait appel à un hébergeur ou à un fournisseur de modèle, ceux-ci deviennent des sous-traitants ultérieurs, et vous devez en connaître la liste.

Conséquence pratique : en cas de contrôle ou de réclamation, c'est vous qu'on interroge. Le fait que votre prestataire ait mal fait son travail ne vous exonère pas, il vous donne un recours contre lui. D'où l'intérêt de regarder le contrat avant, pas après.

Le DPA, et ce qu'il doit contenir

L'article 28 impose un acte juridique écrit. En pratique, un accord de traitement des données qui précise au minimum :

  1. les finalités exactes du traitement, sans formule ouverte du type « et toute finalité connexe »,
  2. les catégories de données traitées,
  3. les durées de conservation, par catégorie,
  4. la liste des sous-traitants ultérieurs et la procédure en cas de changement,
  5. les mesures de sécurité,
  6. le sort des données à la fin du contrat.

Un fournisseur qui n'a pas de DPA prêt à signer n'a pas encore rencontré de client sérieux. Ce n'est pas rédhibitoire chez un jeune éditeur, mais ça vous dit où il en est.

Pourquoi « hébergé en Europe » ne suffit pas

C'est l'argument commercial le plus répandu, et le plus incomplet.

La localisation des serveurs est un élément. Elle ne dit rien de trois autres.

La chaîne de sous-traitance d'abord. Un service hébergé à Paris qui envoie chaque message à une API de génération située ailleurs a organisé un transfert, quelle que soit l'adresse de son propre serveur.

La télémétrie et les journaux ensuite. Les outils de supervision, de suivi d'erreur et d'analyse d'audience sont des traitements à part entière, et ils partent souvent vers des services qu'on n'a pas inventoriés.

Le rattachement juridique enfin. Une infrastructure européenne opérée par une société soumise à une législation extraterritoriale pose une question différente de celle du lieu physique. Le sujet est débattu et évolue ; l'important est de savoir où vous vous situez plutôt que de supposer que la carte règle tout.

La rétention, point faible le plus courant

C'est là que les offres se distinguent le plus, et c'est rarement mis en avant.

Beaucoup d'outils conservent les conversations indéfiniment par défaut, parce que c'est utile pour le produit. Le principe de limitation de la conservation demande l'inverse : garder le temps nécessaire à la finalité, puis supprimer.

Pour du support, une durée courte couvre le besoin. Si vous voulez des statistiques au-delà, elles peuvent être agrégées, ce qui n'exige pas de garder les échanges bruts.

Les questions utiles : quelle est la durée par défaut, est-elle configurable, la suppression est-elle effective ou seulement logique, et que deviennent les sauvegardes.

Entraîner un modèle sur vos conversations

Point à traiter explicitement, parce qu'il est souvent noyé dans les conditions générales.

Utiliser vos conversations pour améliorer un modèle est une finalité différente de « répondre aux clients ». Elle a besoin de sa propre base légale et de sa propre information. Elle pose aussi un risque concret : des données d'un marchand qui influencent les réponses servies à un autre.

Une réponse claire tient en une phrase. Si le fournisseur a besoin d'un paragraphe pour l'expliquer, lisez ce paragraphe attentivement.

Le cloisonnement entre marchands

Question technique, avec une conséquence juridique directe.

Sur une plateforme multi-marchands, chaque installation doit avoir son périmètre de données. Un assistant ne devrait jamais pouvoir consulter le catalogue, les documents ou les conversations d'un autre commerçant, même par erreur de requête.

Les questions à poser : comment l'isolation est-elle assurée, à quel niveau, et qu'est-ce qui l'empêche de céder si une requête est mal formée.

Les six questions qui départagent

Si vous n'en posez que six à un fournisseur, prenez celles-ci.

  1. Où sont hébergées les données, et qui opère l'infrastructure ?
  2. Quelle est la liste complète des sous-traitants ultérieurs ?
  3. Quelle est la durée de conservation par défaut, et est-elle configurable ?
  4. Mes conversations servent-elles à entraîner un modèle ?
  5. Comment l'isolation entre marchands est-elle garantie ?
  6. Le DPA est-il disponible avant signature ?

Les réponses vous en apprendront plus sur la maturité d'un produit que n'importe quelle démonstration.

Ce que fait Selvren

Par cohérence avec ce qui précède : infrastructure européenne, cloisonnement par installation, et pas d'entraînement de modèle sur les conversations des marchands. Notre centre juridique détaille les sous-traitants et les durées de conservation, et le DPA est consultable avant tout engagement.

Nous sommes une jeune société, et une partie de ces engagements se vérifie dans la durée plutôt que sur une page. C'est aussi pour ça que les premiers pilotes sont accompagnés directement par les fondateurs : vous avez quelqu'un à qui poser ces six questions et obtenir une réponse précise.

Pour le versant intégration, voyez le guide PrestaShop. Pour comprendre comment les données sont réellement croisées au moment de répondre, l'article sur le RAG détaille l'architecture.

Questions fréquentes

Un chatbot e-commerce est-il soumis au RGPD ?

Oui dès qu'il traite des données personnelles, ce qui est le cas d'une conversation où un visiteur donne un numéro de commande, un email ou décrit sa situation. Le marchand reste responsable de traitement, le fournisseur du chatbot est sous-traitant.

Faut-il un contrat de sous-traitance avec son fournisseur de chatbot ?

Oui. L'article 28 du RGPD impose un acte juridique entre responsable et sous-traitant. En pratique, un DPA qui liste les finalités, les durées de conservation, les sous-traitants ultérieurs et les mesures de sécurité.

Un hébergement en Europe suffit-il à être conforme ?

Non. La localisation des serveurs est un élément parmi d'autres. Il faut aussi regarder la chaîne de sous-traitance, les transferts éventuels hors UE, les journaux, la télémétrie et la rétention. Un serveur européen appartenant à une société soumise à une législation extraterritoriale ne règle pas tout.

Combien de temps peut-on conserver les conversations d'un chatbot ?

Le temps nécessaire à la finalité annoncée, pas davantage. Pour du support, une durée courte suffit généralement. Une conservation indéfinie pour améliorer un modèle est une finalité distincte, qui demande sa propre base légale et sa propre information.