WhatsApp, RGPD et PCI : guide de conformité pour les hôtels européens

Chaque groupe hôtelier européen avec lequel nous échangeons aboutit à la même question dans les dix minutes qui suivent toute conversation sur WhatsApp : « est-ce seulement légal ? » Oui, sous conditions. WhatsApp peut être exploité dans le respect du RGPD et des règles PCI. Cela exige les bons contrats, les bons flux de données et quelques règles strictes que le personnel n'a pas le droit d'enfreindre.

Les enjeux ne sont pas théoriques. La DPC irlandaise a infligé à Meta une amende de 1,2 Md€ en 2023 pour des transferts visés par Schrems II. Booking.com s'est vu infliger 475 000 € par la DPA néerlandaise en 2021 pour notification tardive de violation. Les hôtels eux-mêmes décrochent rarement des amendes médiatisées. En revanche, ils échouent régulièrement aux audits, perdent des comptes corporate qui exigent une attestation RGPD, et se retrouvent avec un périmètre PCI qu'ils n'avaient pas budgété. Une mauvaise configuration WhatsApp peut aussi déboucher sur des plaintes auprès de la CNIL, de l'ICO ou du Garante émanant d'un seul client estimant que ses messages ont été mal traités.

Il s'agit d'un guide opérationnel, et non d'un avis juridique. Faites valider la check-list par votre DPO ou votre conseil avant toute mise en production. Nous l'avons rédigée pour les directeurs d'hôtel, les responsables IT et les directeurs des opérations groupe qui souhaitent un document concret à remettre au juridique, plutôt qu'une vague assurance « nous utilisons un fournisseur conforme ». Pour la vue d'ensemble des coûts, voir notre pilier coûts WhatsApp pour les hôtels.

Quelles données transitent réellement via WhatsApp dans un hôtel

Avant toute discussion sur la conformité, recensez les données. Dans une configuration WhatsApp typique d'un hôtel européen, le canal véhicule :

• Nom et numéro de mobile du client (toujours)
• Référence de réservation, dates d'arrivée et de départ
• Numéro de chambre, parfois le type de chambre
• Demandes spécifiques (allergies, besoins d'accessibilité, préférences)
• Liens de paiement (URL pointant vers une passerelle hébergée, et non les données de carte elles-mêmes)
• Images de documents lorsque les clients en transmettent spontanément (scans de passeport, photos de pièce d'identité)
• Réclamations en texte libre, comportant parfois des informations relatives à la santé

Les données relatives aux allergies et à l'accessibilité sont des données particulières au sens de l'article 9 du RGPD. Les images de passeport sont des documents d'identité. Une plainte concernant un enfant malade constitue une donnée de santé. WhatsApp n'est pas un canal à faible enjeu sous prétexte qu'il paraît informel pour les clients.

Pour comprendre comment ces données s'articulent avec le reste de votre stack, consultez intégrations et API dans la stack tech hôtelière. Le PMS, le fournisseur de messagerie et toute couche d'IA touchent à ces données, et votre registre des activités de traitement (article 30) doit en rendre compte.

Base légale RGPD pour la messagerie client

L'erreur la plus fréquente que nous observons est celle des hôtels qui invoquent le consentement (article 6(1)(a)) pour tout. Le consentement est la base légale la plus fragile. Il doit être libre, spécifique, éclairé et univoque, et le client peut le retirer à tout moment. Si vous envoyez un message d'arrivée à une personne qui vient de réserver via Booking.com, le consentement n'est pas la bonne base.

Article 6(1)(b) — exécution d'un contrat

Utilisez cette base pour les messages transactionnels liés à la réservation. Instructions d'arrivée, transmission du code de chambre, notifications de chambre prête, rappels de départ, liens de facture. Le client a conclu un contrat en réservant. L'envoi des messages nécessaires à l'exécution de ce contrat est licite sans consentement distinct.

Article 6(1)(f) — intérêt légitime

Utilisez cette base pour les messages d'amélioration du service, les demandes d'avis post-séjour et les alertes opérationnelles qui ne relèvent pas strictement du contrat mais sont raisonnablement attendues. Réalisez une évaluation des intérêts légitimes (LIA) et documentez-la. Les clients doivent pouvoir s'opposer facilement.

Article 6(1)(a) — consentement

Réservez le consentement au marketing. Offres promotionnelles, contenus de type newsletter, messages de retargeting : ces envois requièrent un opt-in explicite, recueilli avant l'émission, avec un mécanisme de retrait clair. Les cases pré-cochées ne fonctionnent pas. L'arrêt Planet49 de 2020 a définitivement enterré ce schéma.

Les hôtels qui tentent de tout faire passer par le consentement se retrouvent avec de faibles taux d'opt-in et des difficultés opérationnelles lorsque les clients se rétractent. Répartir les bases légales par type de message demande davantage de travail en amont, mais bien moins en production.

Les DPA dont vous avez réellement besoin

WhatsApp est exploité par Meta Platforms Ireland Limited pour les utilisateurs européens. Vous utilisez également un Business Solution Provider (BSP) tel que Twilio, 360dialog ou MessageBird. Si vous exécutez une couche d'IA, c'est un sous-traitant supplémentaire.

Avec Meta

Meta agit comme sous-traitant pour le contenu des messages transitant via la WhatsApp Business API. Leurs conditions intègrent des clauses de traitement des données par renvoi. Vous ne signez pas un DPA papier distinct avec Meta. L'accord se compose des conditions de votre BSP et des WhatsApp Business Solution Terms de Meta. Conservez une copie des deux versions acceptées.

Avec votre BSP

Twilio, 360dialog et MessageBird publient chacun leur propre DPA. Signez-les. Confirmez les sous-traitants ultérieurs (ils mentionneront AWS, GCP, parfois des régions Azure). Vérifiez si le BSP traite vos données dans l'UE ou les achemine via les États-Unis. 360dialog est une option dont le siège est dans l'UE, que certains hôtels privilégient pour des raisons de résidence des données.

Avec votre fournisseur d'IA

Si vous exploitez un AI Operator comme Viqal en surcouche de WhatsApp, vous avez également besoin d'un DPA avec ce fournisseur. Vérifiez : la résidence des données dans l'UE, les sous-traitants ultérieurs nommés (le fournisseur du LLM compte ici), les durées de conservation par défaut et le processus de suppression. Pour aller plus loin, consultez notre guide sécurité des données et conformité.

Droits des personnes concernées lorsque les messages vivent dans trois systèmes

Un client écrit à votre DPO pour demander l'ensemble de ses données personnelles. Les journaux WhatsApp se trouvent désormais chez votre BSP, dans la base de votre fournisseur d'IA, possiblement dans votre CRM, ainsi que sur les serveurs de Meta. Les articles 15 (accès), 17 (effacement) et 20 (portabilité) s'appliquent tous.

Construisez un runbook DSAR avant d'en avoir besoin. Étapes qui fonctionnent :

1. Récupérer la fiche client depuis le PMS via son e-mail ou son téléphone
2. Récupérer le fil de conversation auprès du BSP via leur API de conformité
3. Récupérer les données côté IA auprès du fournisseur (il doit exposer un export par contact)
4. Consolider en un export structuré, occulter les identifiants des autres clients
5. Livrer dans le délai d'un mois prévu à l'article 12

L'effacement est plus délicat. Vous ne pouvez pas purger le fil WhatsApp depuis le téléphone du client. Précisez clairement cette limite dans votre politique de confidentialité. Vous supprimez côté serveur, mais le téléphone du client conserve le fil tant qu'il ne l'efface pas lui-même.

Une dernière question relative aux droits : l'article 22 sur la décision automatisée. Si votre AI Operator prend des décisions affectant le client (changements de tarif, attribution de chambre, refus), signalez-le dans la politique de confidentialité et offrez une voie d'examen humain. La plupart des usages d'IA en hôtellerie sont assistifs plutôt que totalement automatisés, mais validez avec votre DPO. La frontière entre « l'IA rédige une réponse, l'humain valide » et « l'IA envoie la réponse directement » est déterminante.

Périmètre PCI — ce qui surprend les hôtels

La règle PCI DSS est simple : si des données de porteur de carte transitent par vos systèmes, ces systèmes entrent dans le périmètre. WhatsApp ne fait pas exception. Si un client saisit un numéro à 16 chiffres dans un fil de discussion et que votre personnel ou votre BSP peut le lire, vous venez d'étendre le périmètre PCI à WhatsApp, à votre BSP, à votre couche d'IA et à tout agent ayant vu le fil.

C'est pourquoi la règle la plus importante de toute politique WhatsApp en hôtellerie est la suivante : n'acceptez jamais de numéros de carte dans le chat. Ni de la part des clients, ni de celle du personnel. Si un client en envoie un, traitez-le comme un incident de sécurité. Supprimez côté serveur, demandez au client d'utiliser un lien de paiement et documentez l'événement.

Les liens de paiement tokenisés vous maintiennent hors du périmètre

Le schéma qui fonctionne : envoyer un lien vers une page de paiement hébergée par un prestataire conforme PCI. Mews Payments, Stripe, Adyen, Worldline et les passerelles régionales équivalentes à Stripe le permettent toutes. Les données de carte du client transitent directement vers la passerelle, ne touchent jamais WhatsApp, ne touchent jamais votre BSP, ne touchent jamais votre fournisseur d'IA. Vous recevez un jeton ou une confirmation de paiement en retour via webhook.

Bien exécuté, ce schéma vous maintient en SAQ A — le questionnaire d'auto-évaluation PCI le plus léger. Mal exécuté (lorsque le personnel saisit occasionnellement des numéros de carte dans le chat pour « aider » les clients), vous basculez en SAQ A-EP, voire pire, et votre QSA n'appréciera guère.

Conservation — trois horloges en parallèle

Vous avez trois horloges de conservation à concilier :

• Les défauts de Meta. Meta conserve le contenu des messages à des fins d'acheminement et de prévention de la fraude, avec des fenêtres plus courtes pour les messages livrés. Les modalités évoluent — vérifiez les WhatsApp Business Solution Terms en vigueur.
• Vos obligations contractuelles. Le droit fiscal exige généralement la conservation des communications liées aux factures pendant 7 à 10 ans selon le pays (HGB allemand, Code de commerce français, HMRC britannique).
• Vos besoins opérationnels. 90 jours couvrent l'essentiel des questions de service. Une année couvre les clients récurrents saisonniers. La durée de vie complète de la réservation, plus une marge, couvre les litiges.

Un schéma viable : conserver le journal de messages actif chez votre BSP pendant 90 jours, archiver les enregistrements structurés (nom du client, dates, montants, référence de réservation) dans votre PMS pour la durée légale de conservation, et purger le contenu en texte libre après 12 mois sauf litige ouvert. Documentez le calendrier. L'article 5(1)(e) impose la limitation de la conservation ; « nous gardons tout indéfiniment » n'est pas une position défendable.

Transferts hors UE et résidence des données dans l'UE

Schrems II a invalidé le Privacy Shield en 2020. Les clauses contractuelles types (CCT) assorties d'une analyse d'impact des transferts constituent désormais le schéma de travail pour tout flux de données vers les États-Unis. L'amende de 1,2 Md€ infligée à Meta en 2023 portait précisément sur cette question.

Ce qui a changé en 2024 : Meta a rapatrié les données des utilisateurs européens dans des centres de données européens pour plusieurs de ses produits. L'acheminement du contenu des messages WhatsApp Business a évolué, mais la réponse n'est pas en une ligne — vérifiez la documentation Meta en vigueur sur la résidence des données pour votre configuration BSP spécifique. Ne présumez pas la résidence dans l'UE sans confirmation.

Pour votre couche d'IA, posez trois questions : où l'application est-elle hébergée, où l'inférence du LLM est-elle exécutée, et un entraînement est-il réalisé sur vos données clients ? « Aucun entraînement sur les données clients » doit figurer au contrat. La région d'inférence compte, car certains fournisseurs acheminent par défaut vers des régions américaines.

La check-list de conformité

Parcourez-la avec votre DPO avant le lancement. Chaque item doit avoir un responsable et une réponse documentée.

Liste longue. Chaque item correspond à une question susceptible d'être posée par un auditeur ou un inspecteur de DPA curieux. Avoir la réponse prête dans un dossier vaut mieux que découvrir au cours d'une enquête que personne n'a documenté la LIA il y a deux ans. Les directeurs au niveau de l'établissement s'accommodent généralement bien des règles. C'est l'alignement de la mémoire opérationnelle de la réception qui exige un travail continu. Renouvelez la formation « pas de numéros de carte dans le chat » tous les six mois, et non une seule fois à l'intégration.

Où Viqal s'inscrit

Nous avons conçu Viqal en pensant aux hôtels européens. Hébergement dans l'UE, sous-traitants ultérieurs nommés, aucun entraînement sur les données clients, contrôles de conservation paramétrables par établissement, et un endpoint d'export DSAR qui restitue un enregistrement structuré par client. Nous avons également publié notre position en matière de sécurité et conformité, qui constitue la 10e partie de notre série sur la stack tech hôtelière.

Rien de tout cela ne vous décharge de vos obligations en tant que responsable de traitement. Vous restez maître des décisions de base légale, de la politique de confidentialité et des réponses aux DSAR. Ce que nous cherchons à faire, c'est réduire la surface contractuelle et technique dont vous avez à vous soucier, afin que le canal WhatsApp ressemble à une relation fournisseur ordinaire plutôt qu'à un champ de mines réglementaire.

Pour la vue d'ensemble opérationnelle et financière, le pilier coûts WhatsApp pour les hôtels détaille la tarification, les catégories de conversation et le calcul du ROI. Conformité et coût sont les deux faces d'une même décision de mise en place. Sécurisez les contrats et le reste suit.