Évaluer un fournisseur de chatbot : DPA, sous-traitants ultérieurs et transferts hors UE

Un fournisseur de chatbot peut présenter une démonstration convaincante, une région d'hébergement dans l'UE et un contrat de traitement des données (DPA) prêt à l'emploi — cela n'empêche pas certaines questions cruciales de rester sans réponse. En effet, le chatbot visible est loin d'être le seul à traiter des données. Souvent, des API de modèles, de l'hébergement, des bases de données vectorielles, des outils d'analyse d'erreurs, de support client, des services e-mail et des sauvegardes interviennent dans la prestation. Pour les exploitants de sites web, c'est la chaîne de traitement vérifiable qui compte, et non les arguments marketing sur le RGPD affichés sur une page de vente.

Cette liste de contrôle vous aide à structurer l'évaluation d'un fournisseur avant l'achat et la mise en ligne. Il s'agit d'un guide pratique et non d'un conseil juridique. Les rôles, les bases légales, les obligations d'information et les mécanismes de transfert doivent être évalués pour chaque cas d'usage concret. En cas de risque élevé, de catégories particulières de données ou de clauses contractuelles ambiguës, il convient de consulter votre délégué à la protection des données (DPD) ou un conseil juridique qualifié.

Comprendre d'abord le flux de données, évaluer le contrat ensuite

La question centrale n'est pas seulement « Où se trouve le serveur ? », mais : quelles données à caractère personnel parviennent à quelle personne morale, quand, pour quelle raison et pendant combien de temps ? Un utilisateur peut saisir des noms, adresses e-mail, numéros de client ou du texte libre dans le chat. De plus, des adresses IP, horodatages, informations sur les appareils, identifiants de session, historiques de conversation, évaluations et journaux techniques sont générés. Même à partir d'une conversation soi-disant anonyme, la combinaison de plusieurs éléments peut rendre une personne identifiable.

Avant d'analyser le contrat, établissez une cartographie simple des flux de données. Elle doit inclure au minimum le widget du navigateur, la plateforme de chatbot, la base de connaissances, le fournisseur de modèles, les services d'analyse et de suivi des erreurs, les accès de support, les sauvegardes et les procédures de suppression. Pour chaque étape, identifiez l'exploitant, le pays, la finalité, les catégories de données, la durée de conservation et les accès distants possibles. Une affirmation telle que « hébergé dans l'UE » ne garantit pas, par exemple, qu'une équipe de support située en dehors de l'Espace économique européen n'a pas accès aux journaux de production.

Déterminer les rôles de protection des données par finalité

La question de savoir si un fournisseur agit en tant que sous-traitant ou en tant que responsable du traitement autonome pour certaines finalités dépend de son activité réelle. Les lignes directrices 07/2020 du Comité européen de la protection des données clarifient cette distinction. Un fournisseur peut traiter des données de conversation sur instruction documentée, tout en revendiquant un rôle différent pour ses propres besoins de sécurité, de facturation ou d'amélioration de produit. Veillez à ce que chaque finalité, le rôle associé et la base légale soient clairement attribués. Un DPA ne couvre pas automatiquement les finalités propres du fournisseur.

Vérifier le DPA : le contenu obligatoire doit correspondre au service réel

L'article 28 du RGPD exige que les responsables du traitement ne fassent appel qu'à des sous-traitants présentant des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées. Le contrat doit notamment préciser l'objet et la durée du traitement, la nature et la finalité, les types de données, les catégories de personnes concernées, ainsi que les droits et obligations du responsable du traitement. S'y ajoutent les instructions documentées, la confidentialité, la sécurité, l'assistance pour les droits des personnes concernées, la suppression ou la restitution des données, ainsi que l'obligation d'information et de collaboration lors des audits.

Ne comparez pas le DPA uniquement avec une liste type, mais avec votre cartographie des flux de données et le forfait réellement souscrit. Un bon contrat décrit clairement le fonctionnement du chat, l'entraînement ou l'indexation de la base de connaissances, la journalisation, les accès de support et les fonctionnalités optionnelles. Les termes vagues tels que « amélioration du service » doivent être détaillés en précisant les données exactes, les finalités, les options disponibles et les rôles correspondants.

• Instructions : Est-il clairement établi que les contenus et métadonnées ne sont traités que pour les finalités documentées du client ? Quelle configuration est considérée comme une instruction ?
• Utilisation pour les modèles : Les prompts, les réponses ou les contenus téléversés sont-ils utilisés pour l'entraînement général des modèles ou l'amélioration du produit ? Si non, cela doit être vérifiable sur les plans contractuel et technique ; si oui, le rôle et la base légale doivent faire l'objet d'une évaluation distincte.
• Suppression : Existe-t-il des délais précis pour l'historique des conversations, les journaux, les index vectoriels, les sauvegardes et les copies de support ? Que se passe-t-il à la fin du contrat ?
• Sécurité : Les contrôles d'accès, le cloisonnement des clients, le chiffrement, la journalisation, la gestion des vulnérabilités et la gestion des incidents sont-ils décrits ?
• Assistance : Le DPA réglemente-t-il de manière pratique l'exportation, la rectification, la suppression, le droit d'accès, les incidents de sécurité et, le cas échéant, les analyses d'impact relatives à la protection des données (AIPD) ?
• Preuves : Des rapports d'audit, des certifications ou d'autres justifications fiables sont-ils disponibles, et s'appliquent-ils exactement aux services et sites utilisés ?

Les certificats et rapports d'audit fournissent des indices utiles, mais ne remplacent ni l'évaluation du traitement spécifique ni des clauses contractuelles adaptées. Même un DPA standardisé ne vaut que par la qualité de ses annexes remplies et leur conformité avec la réalité technique.

Sous-traitants ultérieurs : contrôler les noms, les rôles et les modifications

Conformément à l'article 28, paragraphe 2, du RGPD, un sous-traitant ne peut recruter un autre sous-traitant sans l'autorisation écrite préalable, spécifique ou générale, du responsable du traitement. Dans le cas d'une autorisation générale, il doit informer de tout changement envisagé concernant l'ajout ou le remplacement d'autres sous-traitants et offrir la possibilité de s'y opposer. Les Questions et réponses de la Commission européenne sur les clauses contractuelles types précisent en outre que de simples catégories ne suffisent pas : chaque sous-traitant ultérieur doit être désigné nominalement.

Exigez une liste à jour et exportable comprenant le nom légal, le pays, la prestation exacte et les données concernées. Vérifiez également si une entreprise n'est qu'un partenaire contractuel ou si elle effectue réellement des traitements sur plusieurs sites. Sont particulièrement concernés : les fournisseurs de modèles et d'embeddings, l'hébergement cloud, les bases de données, les CDN, le monitoring, l'analyse d'erreurs, le support, l'e-mail et les sauvegardes. Pour chaque entrée, il doit être possible de déterminer si les données sont stockées, seulement transmises ou consultables par le personnel.

Le processus de modification doit également être évalué : comment les clients sont-ils informés, quel est le préavis et que se passe-t-il en cas d'opposition motivée ? Un e-mail envoyé le jour même du changement, sans possibilité de réaction technique ou contractuelle, a peu de valeur. Assurez-vous qu'une alternative de configuration, la désactivation de la fonctionnalité ou, si nécessaire, une résiliation ordonnée avec exportation des données soient envisageables. Les mêmes obligations de protection des données doivent être répercutées sur les sous-traitants de rang inférieur ; le sous-traitant principal reste responsable envers le responsable du traitement de l'exécution de leurs obligations.

Transferts vers des pays tiers : vérifier le mécanisme et son efficacité réelle

Le chapitre V du RGPD s'applique aux transferts de données à caractère personnel vers des pays tiers et aux transferts ultérieurs. Un transfert ne résulte pas uniquement d'un stockage permanent ; un accès administratif, un accès de support ou une consultation par un service situé hors de l'EEE peuvent également constituer un transfert. Associez donc à chaque flux de votre cartographie un pays de destination, un destinataire et un mécanisme de transfert.

1. Décision d'adéquation : Consultez la liste régulièrement mise à jour par la Commission européenne pour vérifier si la décision, le territoire, le secteur et le destinataire spécifique sont couverts. Dans le cas de cadres restreints, la simple présence d'un établissement dans un pays ne suffit pas.
2. Garanties appropriées : En l'absence de décision d'adéquation applicable, des instruments prévus à l'article 46 du RGPD peuvent être envisagés selon la situation. Les clauses contractuelles types (CCT) de la Commission européenne sont fréquemment utilisées. Le module, les parties, les annexes, la description du transfert et les mesures techniques doivent correspondre à la chaîne réelle.
3. Évaluation de l'efficacité : La signature de CCT ne met pas automatiquement fin à l'analyse. Les recommandations finales 01/2020 du CEPD décrivent une démarche fondée sur le risque : connaître les transferts, identifier l'instrument, évaluer le droit et la pratique du pays tiers, définir si nécessaire des mesures complémentaires, accomplir les formalités et réévaluer régulièrement.

Les mesures techniques complémentaires doivent être adaptées au risque spécifique. Le chiffrement, par exemple, n'est pertinent que si la gestion des clés, les droits d'accès et la finalité du traitement sont pris en compte. Un fournisseur de modèles devant traiter du texte en clair et ayant lui-même accès aux clés présente une situation très différente de celle d'un stockage de sauvegarde chiffré. Des affirmations vagues comme « AES-256 » ou « conforme au RGPD » ne remplacent pas cette analyse. De plus, les dérogations de l'article 49 du RGPD ne constituent pas une solution standard pour des traitements SaaS récurrents et planifiés.

Exemple pratique : région UE avec chaîne de services globale

Imaginons un chatbot dont la base de données principale est située à Francfort. Toutefois, les réponses sont générées par l'API d'un modèle appartenant à une entreprise américaine, les rapports d'erreur sont transmis à un autre service, et une équipe de support mondiale peut accéder aux journaux de conversation en cas d'escalade. Dans ce cas, déclarer que les « données sont stockées dans l'UE » ne décrit qu'une partie du système.

La due diligence doit distinguer quatre questions : quels contenus quittent l'EEE pour générer les réponses du modèle ? Des prompts y sont-ils conservés ou réutilisés à d'autres fins ? Les rapports d'erreur contiennent-ils du texte en clair, des identifiants ou uniquement des données techniques minimisées ? Dans quelles conditions l'équipe de support située hors EEE peut-elle y accéder ? C'est seulement après cette analyse que l'outil de transfert, les mesures complémentaires et le risque résiduel peuvent être évalués.

Sur le plan technique, l'exploitant du site web peut souvent réduire les risques : désactiver les champs de journalisation inutiles, caviarder les saisies avant les appels externes, appliquer des durées de conservation courtes, séparer les zones sensibles du bot public, isoler les sources de connaissances par client et journaliser les accès de support soumis à autorisation. Pour découvrir comment séparer clairement un bot public d'un espace client, consultez l'article Chatbot IA authentifié vs portail client. Pour les fichiers téléversés, la liste de contrôle sur la vérification des fichiers, la protection des données et le transfert complète l'évaluation des fournisseurs.

Prendre une décision objective grâce au système de feux tricolores

Point de contrôle	Vert	Orange	Rouge
Flux de données	Complet, à jour et adapté au forfait souscrit	Accès ou lieux de stockage isolés non précisés	Simple argument marketing sur la région UE
DPA	Finalités, données, délais et assistance détaillés	Ajustements nécessaires avant le lancement	Aucune instruction claire ni obligation de suppression
Sous-traitants ultérieurs	Liste nominative avec pays et rôle attribué	Procédure de modification peu pratique	Simples catégories ou chaîne inconnue
Transferts hors UE	Mécanisme, portée et évaluation documentés	Mesures encore à vérifier	Le « serveur UE » est censé tout justifier
Exploitation	Responsable désigné, revue planifiée et sortie testée	Preuves fournies sans revue régulière	Aucun suivi après la signature du contrat

Un feu orange ne signifie pas nécessairement qu'il faut rejeter le fournisseur. Il exige cependant la désignation d'un responsable, une échéance et un critère de validation vérifiable. En revanche, un feu rouge sur un maillon essentiel de la chaîne de traitement doit bloquer la mise en production jusqu'à ce que le contrat, la configuration ou le choix du prestataire soient corrigés. Documentez également les risques résiduels acceptés ainsi que l'identité de la personne ayant pris la décision.

Liste de contrôle synthétique pour le lancement

• La cartographie des flux de données et les rôles par finalité sont validés.
• Le DPA et ses annexes correspondent au forfait, aux fonctionnalités, aux types de données et aux durées de conservation.
• Tous les sous-traitants ultérieurs sont recensés de manière nominative avec leur pays, leur rôle et la procédure de modification.
• Chaque transfert vers un pays tiers s'appuie sur un mécanisme adapté et récemment vérifié, complété si nécessaire par des mesures adéquates.
• L'entraînement des modèles ou toute autre utilisation propre des données de chat est clarifié(e) et configuré(e) conformément aux accords.
• La journalisation, l'accès au support, l'exportation des données, la suppression et la fin du contrat ont été testés en pratique.
• La politique de confidentialité et l'interface de chat expliquent le traitement de manière claire ; les utilisateurs ne sont pas incités à fournir des données sensibles inutiles.
• L'opportunité de réaliser une analyse d'impact relative à la protection des données (AIPD) pour ce cas d'usage a été vérifiée.
• Un responsable assure la veille concernant les modifications apportées aux sous-traitants ultérieurs, aux mécanismes de transfert, aux fonctionnalités et aux garanties de sécurité.

Pour aller plus loin, il est utile de consulter notre vue d'ensemble sur le Chatbot IA et le RGPD ainsi que notre guide dédié à l'analyse de chatbot axée sur la sobriété des données. Vous éviterez ainsi de traiter les achats, la configuration technique et l'exploitation quotidienne comme des projets isolés.

Poursuivre la vérification après la signature du contrat

La due diligence ne s'arrête pas à l'archivage d'un dossier PDF. Établissez une fréquence de révision fixe ainsi que des contrôles déclenchés par des événements spécifiques. Les déclencheurs incluent : l'ajout d'un nouveau sous-traitant ultérieur, le changement de fournisseur de modèle, le déploiement de nouvelles fonctionnalités, la modification des lieux de stockage, la survenance d'un incident de sécurité, l'expiration de certifications ou l'évolution d'une décision d'adéquation. La liste actuelle des sous-traitants ultérieurs et les versions clés des contrats doivent être archivées avec leur date afin de garantir la traçabilité des modifications.

Le critère d'évaluation pratique est simple : votre équipe peut-elle expliquer, pour chaque flux de données pertinent, qui traite quoi, pourquoi, où cela se produit, combien de temps les données sont conservées, quelles mesures de protection s'appliquent et comment s'effectue la réversibilité ? Lorsque ces réponses sont étayées par des preuves, une simple promesse de conformité se transforme en une décision d'achat robuste. Si des étapes clés restent inconnues, le chatbot ne devrait pas encore traiter de données réelles d'utilisateurs.