RGPD et IA conversationnelle : ce qu'une clinique esthétique doit vérifier avant de choisir un outil

Une clinique esthétique qui déploie un assistant IA pour répondre à ses patients reste, au sens du RGPD, responsable du traitement des données de ces patients — même si c’est un prestataire externe qui fait tourner l’outil. Ce que la clinique doit vérifier avant de choisir un outil se résume à quatre points concrets : qui agit comme sous-traitant et sur quelle base contractuelle, où sont stockées les données et par qui elles sont consultées, ce qu’il advient des données en cas de résiliation, et si les échanges peuvent contenir des données de santé nécessitant une protection renforcée. Ce dernier point est souvent négligé alors qu’il concerne directement le secteur esthétique.

Pourquoi la clinique reste responsable, même en sous-traitant l’outil

Le RGPD distingue le « responsable de traitement » (celui qui décide pourquoi et comment les données sont utilisées) du « sous-traitant » (celui qui traite les données pour le compte du premier, selon ses instructions). Quand une clinique installe un assistant IA sur son site ou ses réseaux sociaux pour dialoguer avec ses patients, c’est elle qui reste responsable de traitement : c’est elle qui décide de collecter ces messages, dans quel but, et c’est à elle que les patients doivent pouvoir s’adresser pour exercer leurs droits (accès, rectification, effacement).

L’éditeur de l’outil IA agit comme sous-traitant, dans le cadre d’un contrat de sous-traitance (souvent appelé DPA, Data Processing Agreement) qui doit exister entre la clinique et ce prestataire, conformément à l’article 28 du RGPD. Une clinique qui ne peut pas mettre la main sur ce contrat, ou dont le prestataire ne peut pas expliquer clairement ce rôle, a un problème de conformité — indépendamment de la qualité technique de l’outil.

Les conversations patients peuvent contenir des données de santé

C’est le point le plus spécifique au secteur esthétique et le plus souvent sous-estimé. Un message expliquant vouloir « refaire son nez », demandant des informations sur une intervention chirurgicale, ou mentionnant une pathologie de peau relève potentiellement de la catégorie des données de santé au sens de l’article 9 du RGPD — une catégorie dite « particulière », soumise à des garanties renforcées par rapport à une donnée de contact classique comme un nom ou un numéro de téléphone.

Concrètement, cela signifie qu’un outil conçu uniquement pour capturer des coordonnées de contact (nom, téléphone, e-mail) n’est pas nécessairement conçu pour héberger en toute sécurité le contenu détaillé d’un échange évoquant une intervention médicale. Avant de choisir un outil, il est légitime de demander à l’éditeur comment il traite spécifiquement ce type de contenu, et pas seulement les coordonnées associées.

Pourquoi l’architecture « une instance par clinique » n’est pas un détail technique

Beaucoup d’outils d’assistants conversationnels fonctionnent sur une architecture mutualisée : toutes les clientes partagent la même base de données, les mêmes serveurs, avec une simple séparation logique (un identifiant de compte) entre les données de chaque clinique. Ce modèle fonctionne, mais il concentre le risque : une faille de sécurité ou une erreur de configuration peut, en théorie, exposer les données de plusieurs cliniques à la fois.

Une architecture où chaque clinique dispose de sa propre instance isolée réduit ce risque par construction : les données d’une clinique ne transitent jamais par les mêmes espaces de traitement que celles d’une autre. C’est le choix retenu par CliniqoAI, où seule l’infrastructure de connexion aux canaux Meta (WhatsApp, Instagram, Messenger) est centralisée pour la gestion technique des autorisations, tandis que les conversations et la base de connaissances de chaque clinique restent propres à son instance. Pour une clinique, cela simplifie aussi une question très concrète : en cas de contrôle ou de demande d’un patient, il est plus simple de démontrer où se trouvent exactement ses données lorsqu’elles ne sont pas mélangées à celles d’autres établissements.

Ce qu’il faut vérifier avant de signer

Quatre questions permettent d’évaluer rapidement un outil sous l’angle RGPD, au-delà de ses fonctionnalités commerciales :

1. Existe-t-il un contrat de sous-traitance (DPA) ? Un éditeur sérieux doit pouvoir le fournir sans détour.
2. Où les données sont-elles hébergées, et par quel sous-traitant ultérieur (hébergeur, fournisseur d’IA) ? Si un sous-traitant est situé hors de l’Union européenne, un mécanisme de transfert encadré (clauses contractuelles types, décision d’adéquation) doit être identifié.
3. Que devient l’historique des conversations en cas de résiliation ? Une suppression ou une restitution doit être prévue contractuellement, pas laissée à l’appréciation du prestataire.
4. L’outil est-il conçu pour des échanges pouvant toucher à des données de santé ? Ou seulement pour capturer des coordonnées de contact classiques ?

Ce texte n’est pas un avis juridique

Cet article vise à donner à une clinique les bons réflexes et le bon vocabulaire pour interroger un prestataire — il ne remplace pas l’avis d’un délégué à la protection des données ou d’un conseil juridique sur votre situation spécifique, en particulier si votre clinique traite déjà des données de santé dans d’autres systèmes (dossier patient, logiciel médical) et souhaite s’assurer de la cohérence globale de sa conformité RGPD.

Chez CliniqoAI, cette logique d’isolation par clinique et de rôle clair de sous-traitant est détaillée dans notre politique de confidentialité, que nous transmettons à chaque clinique cliente pour qu’elle puisse vérifier elle-même ces points avant de nous confier ses données.