Cet article ne remplace pas l’avis d’un juriste ou de votre délégué à la protection des données. C’est une grille de lecture opérationnelle, pour un exploitant qui veut savoir quoi vérifier avant de brancher un chat sur son site.
Les arbitrages qui dépendent de votre configuration précise doivent être validés par un professionnel du droit.
Le sujet remonte de trois façons.
- Un client qui demande où vont ses messages
- Un assureur qui pose la question dans un questionnaire de risque cyber
- Un DPO de collectivité qui bloque un projet d’office de tourisme
Dans les trois cas, « notre éditeur est conforme RGPD » ne veut rien dire. La bonne réponse est un dossier de douze points, dont dix relèvent de vous et deux de votre fournisseur. Pour resituer le sujet dans le cadre plus large d’un agent conversationnel, voir notre article dédié.
Le cadre RGPD d’un chat web
Un chat sur un site d’hébergement traite des données personnelles. Ce n’est pas discutable.
Même sans formulaire. Le contenu des messages contient presque toujours un nom, des dates de séjour, une composition familiale, parfois une adresse e-mail laissée pour être rappelé. S’y ajoutent les données techniques : adresse IP, identifiant de session.
Quatre qualifications structurent tout le reste. Les trois premières sont des rôles.
| Rôle | Qui c’est | Ce que ça implique |
|---|---|---|
| Responsable de traitement | Vous | Vous décidez du chat, du but et des données ; cette responsabilité ne se délègue pas à l’éditeur |
| Sous-traitant | L’éditeur | Il traite pour votre compte, sur vos instructions : contrat obligatoire |
| Sous-traitant ultérieur | Le fournisseur de modèle, souvent | Vous devez savoir qui il est, où il opère, ce qu’il fait des contenus transmis |
La quatrième qualification : la finalité. Chacune doit être identifiée séparément.
- Répondre aux questions des visiteurs
- Améliorer le produit à partir des conversations
- Entraîner un modèle avec vos échanges — nettement plus sensible
Ces trois finalités n’ont pas la même base légale et ne se traitent pas d’un seul bloc.
La doctrine de référence date de 2021
Voici l’angle que personne ne relève, et qui explique beaucoup de la confusion actuelle.
Le fait. La publication de référence de la CNIL consacrée aux chatbots date de février 2021. Elle est antérieure à l’arrivée grand public des grands modèles de langage.
Ce n’est pas un vide juridique. Le RGPD s’applique pleinement, quelle que soit la technologie : licéité, minimisation, limitation des durées et sécurité sont neutres par construction. Mais la doctrine spécifique aux chatbots a été écrite pour un objet différent de celui que vous déployez aujourd’hui.
Ce que les modèles génératifs ont changé
| Sujet | Chatbot à scénario, 2021 | Agent génératif, aujourd’hui |
|---|---|---|
| Entrée du visiteur | Boutons et arbre de décision : données prévisibles, bornées par avance | Texte libre : vous ne contrôlez plus ce qui entre. Le changement le plus lourd pour la minimisation |
| Chaîne de sous-traitance | Tout tourne chez l’éditeur | Éditeur, infrastructure, fournisseur de modèle, parfois indexation : chaque maillon est à identifier et à contractualiser |
| Contenu transmis au tiers | Des données de formulaire | Des fragments de conversation en langage naturel, chargés d’informations que personne n’avait prévu de collecter |
| Mémorisation | Aucune | Un modèle réentraîné sur des conversations peut en restituer des fragments : d’où la clause anti-entraînement |
Conclusion pratique. Ne cherchez pas une réponse prête à l’emploi dans la doctrine existante pour chacune de vos questions. Raisonnez à partir des principes, documentez vos choix, gardez la trace de votre raisonnement.
C’est exactement ce que le RGPD attend d’un responsable de traitement, et c’est ce qui vous protège en cas de contrôle.
Les 12 points de la checklist
Le dossier tient en douze lignes. Voici la vue d’ensemble, puis le détail.
| # | Point | Le livrable attendu |
|---|---|---|
| 1 | Base légale | Une base écrite, finalité par finalité |
| 2 | Information des personnes | Une phrase dans le widget et un lien vers la politique |
| 3 | Cookies et traceurs | La liste des traceurs du widget, finalité et durée |
| 4 | Minimisation | Aucun champ inutile dans le parcours |
| 5 | Durée de conservation | Une durée définie, documentée, appliquée automatiquement |
| 6 | Sous-traitance | Le DPA signé et la liste des sous-traitants ultérieurs |
| 7 | Transferts hors UE | La localisation de chaque maillon, vérifiée à date |
| 8 | Sécurité | Une annexe technique écrite, pas une brochure |
| 9 | Droits des personnes | Une extraction et une suppression testées avant signature |
| 10 | Registre des traitements | Une ligne dédiée au chatbot |
| 11 | Analyse d’impact | La question posée, la réponse documentée |
| 12 | Journalisation | La trace des accès et des modifications |
Points 1 à 4 : avant d’ouvrir le chat
1. Base légale. Identifiez-la et écrivez-la. Répondre aux questions d’un visiteur relève généralement de l’intérêt légitime, ou de l’exécution du contrat s’il s’agit d’un client dont le séjour est confirmé.
Le consentement est rarement la bonne base pour la conversation elle-même — il l’est en revanche pour un usage marketing ultérieur. Vigilance : une base légale par finalité.
2. Information des personnes. Le visiteur doit savoir, avant d’écrire : qu’il parle à un système automatique, qui est responsable, dans quel but les messages sont traités, combien de temps ils sont conservés, où ils sont hébergés, comment exercer ses droits.
En pratique : une phrase d’accueil claire dans le widget, et un lien vers votre politique de confidentialité accessible depuis le chat lui-même. Pas un renvoi vers un document de douze pages sans point d’entrée.
3. Consentement cookies et traceurs. Distinguez le strictement nécessaire du reste. Le maintien de l’état de la conversation pendant la visite est fonctionnel et n’exige pas de consentement. Un traceur de mesure d’audience, de scoring commercial ou de publicité en exige un, recueilli avant dépôt.
Demandez à votre éditeur la liste exacte des traceurs déposés par son widget, leur finalité et leur durée. Cette liste doit figurer dans votre inventaire.
4. Minimisation. Ne collectez que le nécessaire : pas de demande d’identité pour répondre à une question sur le wifi, pas de champ téléphone obligatoire, pas de collecte de date de naissance. Le point délicat, propre aux agents génératifs : le visiteur peut écrire beaucoup plus que ce que vous demandez.
Points 5 à 7 : durée, contrat, localisation
5. Durée de conservation. Définissez-la, écrivez-la, appliquez-la automatiquement. Le RGPD ne fixe pas de chiffre : il exige que la durée soit justifiée par la finalité et documentée.
Trois questions à poser à l’éditeur : la durée est-elle configurable ? La suppression est-elle effective, sauvegardes comprises, et sous quel délai annoncé ? Que devient l’historique après résiliation ?
6. Sous-traitance et contrat de traitement. Un DPA signé avec l’éditeur est obligatoire dès qu’il traite des données pour votre compte. Obtenez aussi la liste des sous-traitants ultérieurs, avec leur rôle et leur localisation. Les dix clauses à lire attentivement sont détaillées plus loin.
7. Transferts hors Union européenne. Localisez les traitements. Si un maillon de la chaîne opère hors UE, un mécanisme de transfert valable est requis, et le statut de ces mécanismes évolue : vérifiez-le à la date de votre analyse, pas d’après une note de l’année précédente.
Le moyen le plus simple de fermer le sujet : exiger par écrit la localisation de chaque maillon, support technique compris. Groomy fournit un DPA standardisé sans négociation, ce qui simplifie considérablement ce point du dossier. Notre article chatbot français : souveraineté, hébergement et RGPD détaille les quatre niveaux à vérifier chez un éditeur.
Points 8 à 12 : sécurité, droits, documentation
8. Sécurité. Chiffrement en transit et au repos, contrôle des accès côté éditeur, journalisation des accès administrateurs, procédure de notification en cas de violation avec un délai contractuel qui vous permette de respecter le vôtre.
Demandez des éléments écrits. Une déclaration commerciale de type « données sécurisées » n’a aucune valeur probante. Méfiez-vous aussi des éditeurs qui laissent entendre qu’ils détiennent des certifications sans jamais produire le certificat correspondant.
9. Droits des personnes. Accès, rectification, effacement, opposition, limitation. Vous devez pouvoir retrouver, extraire et supprimer les conversations d’une personne identifiée. Testez-le avant de signer : un outil sans recherche par identifiant vous met en difficulté à la première demande sérieuse.
10. Registre des traitements. Ajoutez une ligne dédiée au chatbot : finalités, catégories de personnes et de données, destinataires et sous-traitants, durées, mesures de sécurité, transferts éventuels. C’est le premier document demandé en cas de contrôle, et il se remplit en vingt minutes.
11. Analyse d’impact. Posez-vous la question et documentez la réponse, y compris si elle est négative. Un chatbot d’information sur un site d’hébergement ne coche généralement pas les critères qui la rendent obligatoire. Une décision automatisée à effet juridique, ou des données de santé à grande échelle, changeraient la donne.
12. Journalisation et traçabilité. Conservez la trace de qui accède aux conversations côté équipe, et de ce qui est modifié dans la base de connaissances. C’est utile pour la sécurité, indispensable en cas d’incident, et cela sert aussi la qualité des réponses.
Données sensibles glissées dans la conversation
C’est le sujet que les argumentaires commerciaux évitent, et c’est pourtant le plus fréquent en pratique.
Vous ne demandez rien de sensible. Aucun formulaire médical, aucune question de santé. Et pourtant, tous les jours, des visiteurs écrivent spontanément des choses de cette nature.
Ce qui arrive vraiment dans un chat
| Ce que le visiteur écrit | Ce que c’est juridiquement |
|---|---|
| « Ma fille est allergique à l’arachide, le petit-déjeuner est-il adapté ? » | Une information de santé, transmise sans y penser |
| « Mon père se déplace en fauteuil, la salle de bain est-elle accessible ? » | Une donnée relative à l’état de santé, à finalité légitime |
| « Je viens avec mes enfants un week-end sur deux, en garde alternée. » | Une information sur la vie privée, non sollicitée |
| « Je sors d’une opération, y a-t-il un ascenseur ? » | Une donnée de santé, dans une question purement pratique |
| « J’ai besoin de conserver un traitement au frais. » | Une donnée de santé, encore, sans le moindre formulaire |
Ces messages sont légitimes, utiles au client, et impossibles à empêcher : vous ne pouvez pas interdire à un visiteur d’écrire ce qu’il veut dans un champ de texte libre.
Les cinq mesures à mettre en place
| Mesure | Concrètement |
|---|---|
| Ne pas conserver plus longtemps que nécessaire | Une conversation contenant une donnée de santé n’a pas à rester six mois dans une interface ouverte à toute l’équipe |
| Ne jamais verser ces contenus dans la base | Une base documentaire contient vos informations d’établissement, jamais des échanges avec des personnes identifiables |
| Escalader plutôt que traiter | Santé, allergie, accessibilité : transfert immédiat vers un humain, sans tentative de réponse |
| Limiter les accès en interne | Toute l’équipe n’a pas besoin de tout lire : un accès par rôle, avec journalisation |
| Le mentionner dans votre information | « Merci de ne pas communiquer d’informations médicales ou de données bancaires dans ce chat » |
La règle la plus souvent enfreinte est celle de la base de connaissances. Elle est bafouée par tous ceux qui alimentent leur base avec un export de boîte mail.
La mention ne vous exonère de rien. Elle réduit le volume, démontre votre diligence et fait partie du dossier. C’est déjà beaucoup.
Le DPA : 10 clauses à vérifier
Demandez le document, lisez ces dix points, et gardez la version signée. Un éditeur qui ne fournit pas de DPA doit être écarté, sans discussion.
| # | Clause | Ce qu’il faut y trouver |
|---|---|---|
| 1 | Objet et durée du traitement | Une description précise, pas « fourniture du service » |
| 2 | Nature et finalités | Ce que l’éditeur fait exactement des données, finalité par finalité |
| 3 | Usage pour l’entraînement | Une interdiction explicite d’utiliser vos conversations pour entraîner des modèles, ou un mécanisme d’opposition clair |
| 4 | Liste des sous-traitants ultérieurs | Identité, rôle, localisation, et procédure d’information en cas de changement |
| 5 | Localisation des traitements | Le pays, pour chaque maillon, y compris le support technique |
| 6 | Mesures de sécurité | Une annexe technique, pas une phrase de brochure |
| 7 | Notification des violations | Un délai chiffré compatible avec votre propre obligation |
| 8 | Assistance aux droits des personnes | L’éditeur s’engage à vous aider à répondre aux demandes d’accès et d’effacement |
| 9 | Sort des données en fin de contrat | Restitution puis suppression, avec un délai et une attestation |
| 10 | Audit et documentation | Votre droit d’obtenir les éléments nécessaires pour démontrer la conformité |
Deux questions complémentaires, à poser par écrit. Les conversations sont-elles utilisées pour améliorer le service, et si oui sous quelle forme ? Quel est le délai de suppression effective, sauvegardes incluses ? Les réponses vous en apprendront plus que toute la documentation commerciale.
Ce que l’AI Act ajoute au RGPD
Les deux textes se cumulent : le RGPD protège les données personnelles, le règlement sur l’IA encadre le système lui-même, son usage et l’information de ceux qui l’utilisent.
| Point | Ce qu’il impose | Repère |
|---|---|---|
| Transparence, article 50 | Informer la personne qu’elle interagit avec une IA, sauf lorsque c’est manifestement évident | Applicable à compter du 2 août 2026 |
| Littératie IA, article 4 | Un niveau suffisant de compréhension chez les personnes qui utilisent le système | Applicable depuis le 2 février 2025 |
| Fournisseur ou déployeur | Celui qui met le système sur le marché n’a pas les obligations de celui qui l’utilise | Un hôtel qui installe un agent est déployeur |
| Sanctions, article 99 | Un régime propre au règlement | Il s’ajoute à celui du RGPD |
Traduction opérationnelle. Votre widget dit ce qu’il est dès le premier message. Et votre réception suit une session de formation courte : ce que fait l’agent, ce qu’il ne fait pas, quand reprendre la main.
Gardez les proportions. Ces obligations restent légères pour un chatbot d’information, qui ne relève pas des catégories à haut risque du règlement. L’essentiel de votre effort doit rester sur le dossier RGPD. Pour le tourisme, voir sécurité et RGPD d’un chatbot IA tourisme.
Le dossier à constituer, dans l’ordre
Trois heures de travail suffisent à passer d’un « on ne sait pas » à un dossier présentable.
| Ordre | Action | Repère |
|---|---|---|
| 1 | Écrivez la ligne du registre des traitements | Vingt minutes, et c’est le premier document réclamé |
| 2 | Réclamez le DPA et lisez les dix clauses | Pas de DPA : arrêtez le projet et changez de fournisseur |
| 3 | Fixez et faites appliquer une durée de conservation | Vérifiez qu’elle est effective, pas seulement annoncée |
| 4 | Ajoutez le paragraphe chatbot à votre politique | Plus une phrase d’identification dans le widget |
| 5 | Configurez l’escalade santé, accessibilité, litige | Conformité et qualité de service au même endroit |
| 6 | Formez votre équipe en trente minutes | C’est l’obligation de littératie, et cela évite les incidents |
Si le dossier remonte d’un assureur, d’un DPO ou d’une collectivité, ce sont ces six éléments qui débloquent la situation.
Nos engagements de sécurité, de sous-traitance et de conformité sont détaillés sur la page sécurité ; le lieu d’hébergement des données est communiqué sur demande. Pour toute question qui dépasse ce cadre, notre équipe transmet les éléments contractuels via la page contact.
Pour une vision d’ensemble de la conformité côté hébergeur, voir RGPD et IA dans l’hospitality. Et pour ce qu’est réellement un agent IA, notre guide de référence pose les bases.
Questions fréquentes
Un chatbot est-il conforme au RGPD ?
Un chatbot n'est jamais conforme ou non conforme en soi : c'est le traitement que vous en faites qui l'est. Un même outil peut être parfaitement conforme chez un exploitant et hors des clous chez un autre, selon l'information donnée aux visiteurs, la durée de conservation retenue, le contrat signé avec l'éditeur et le lieu d'hébergement des données. La conformité se construit en douze points, pas en une case à cocher.
Combien de temps faut-il conserver les conversations d'un chatbot ?
Le RGPD n'impose pas de durée chiffrée : il exige une durée justifiée par la finalité et écrite quelque part. En pratique, la plupart des exploitants retiennent une durée courte pour l'exploitation courante, puis un archivage ou une suppression selon les besoins de preuve. Ce qui compte pour un contrôle, c'est que la durée soit définie, documentée, appliquée automatiquement, et cohérente avec ce que vous annoncez aux visiteurs.
Faut-il le consentement du visiteur avant d'afficher un chat ?
Il faut distinguer deux choses. Le dépôt de traceurs sur le terminal relève des règles cookies : un cookie strictement nécessaire au fonctionnement du chat n'exige pas de consentement, un traceur de mesure d'audience ou de publicité oui. Le traitement des données de la conversation, lui, repose le plus souvent sur l'intérêt légitime ou l'exécution du contrat, pas sur le consentement. Une bannière n'est donc pas la réponse universelle.
Qu'est-ce qu'un DPA et pourquoi l'exiger de son éditeur ?
Un DPA, ou accord de traitement des données, est le contrat prévu par l'article 28 du RGPD entre le responsable de traitement (vous) et son sous-traitant (l'éditeur). Il est obligatoire dès que l'éditeur traite des données personnelles pour votre compte, ce qui est toujours le cas avec un chatbot. Demandez-le systématiquement : un éditeur sérieux le fournit sans discuter, et son absence est un signal d'alerte suffisant pour écarter un fournisseur.
Faut-il une analyse d'impact pour un chatbot d'hôtel ?
Dans la plupart des cas, un chatbot d'information sur un site d'hébergement ne remplit pas les critères qui rendent l'analyse d'impact obligatoire : pas de décision automatisée à effet juridique, pas de surveillance systématique, pas de traitement de données sensibles à grande échelle par conception. Cela dit, l'appréciation dépend de votre configuration réelle, et une analyse même non obligatoire reste un bon exercice de documentation.
Que change l'AI Act par rapport au RGPD pour un chatbot ?
Le RGPD protège les données personnelles, le règlement européen sur l'IA encadre le système lui-même. Les deux se cumulent. Le point le plus concret pour un exploitant est l'obligation de transparence de l'article 50, applicable à compter du 2 août 2026 : le visiteur doit savoir qu'il parle à une machine. S'y ajoute l'obligation de littératie IA de l'article 4, applicable depuis le 2 février 2025, qui vous demande de former les personnes qui utilisent le système.