Tourisme et technologie

RGPD et IA sur votre site touristique : 5 décisions réelles

Publié le 6 min de lecture

Comptoir de réception avec une boîte en verre contenant une clé dorée, à côté d'une carte imprimée et d'un stylo-plume. Image générée avec l'IA.

Sur mon site, il y a un outil gratuit, le Génie du Prompting, qui traite le texte des utilisateurs avec un modèle d'IA. Vous décrivez en deux phrases ce que vous voulez obtenir, vous choisissez pour quelle IA — ChatGPT, Claude, Gemini, Midjourney, Veo et d'autres, en texte, image, vidéo, agents et SEO — et il vous rend un prompt affiné pour ce modèle précis, prêt à coller. Sans inscription. Le construire m'a obligé à répondre, par des décisions concrètes, aux mêmes questions que se pose tout acteur touristique qui ajoute un chatbot, un formulaire intelligent ou de la simple analytique : que je conserve, que j'annonce, et à qui je demande la permission. Voici les cinq décisions prises et pourquoi — avec l'avertissement préalable que je ne suis pas avocat, et que ceci est de l'expérience documentée, pas du conseil juridique.

1. Le consentement doit bloquer pour de vrai

L'erreur la plus répandue sur les sites touristiques est le bandeau décoratif : il apparaît, demande la permission... pendant que les scripts de mesure ont déjà chargé. Ce n'est pas un consentement ; c'est du décor.

Dans mon cas, le gestionnaire de balises — et avec lui toute l'analytique — ne se charge pas avant que l'utilisateur clique sur accepter. S'il refuse, il ne se charge jamais. Et refuser coûte exactement le même clic qu'accepter, critère que l'autorité espagnole de protection des données fixe pour les bandeaux. Le test décisif est technique et à la portée de tous : ouvrez votre site en fenêtre privée, n'acceptez rien, et regardez dans les outils du navigateur quelles requêtes partent. Ce qui charge avant votre « oui » vous trahit.

2. La meilleure donnée est celle qu'on ne conserve pas

Quand j'ai conçu le registre d'usage de mon outil, la décision la plus importante fut négative : ne pas conserver les adresses IP. Je n'en avais aucun usage utile, et chaque donnée personnelle stockée est une responsabilité contractée — il faut la protéger, la déclarer et pouvoir l'effacer à la demande.

C'est le principe de minimisation appliqué avec une logique d'affaires : avant de conserver un champ, la question n'est pas « pourrait-il servir un jour ? » mais « quelle décision concrète prendrai-je avec ? ». Sans réponse claire, dehors. Pour un hôtel ou une agence, le même filtre appliqué au formulaire de réservation élimine souvent la moitié des champs — et améliore la conversion au passage, car chaque champ en trop fait fuir.

3. Si une IA traite du texte, on le dit — clairement et à côté

Mon outil envoie le texte de l'utilisateur à un fournisseur d'IA pour traitement. Cela s'annonce, et s'annonce là où c'est utilisé : un avis court près du formulaire lui-même — le texte est traité par IA, ne saisissez pas de données personnelles ni confidentielles, il est conservé de façon anonyme — avec un lien vers une page de conditions détaillant ce qui est stocké, combien de temps et avec quels droits. Double couche : avis bref au point d'usage, détail complet à un clic.

En le construisant, je me suis posé la question que tout le monde se posera : si j'utilise le quota gratuit de l'API Gemini, Google entraîne-t-il ses modèles avec ce texte ? Hors d'Europe, il le peut. En Europe, non : les conditions de l'API Gemini prévoient que dans l'Espace économique européen, en Suisse et au Royaume-Uni, les mêmes conditions d'utilisation des données que la version payante s'appliquent à tout le service, quota gratuit compris. Et ces conditions disent que Google n'utilise ni les prompts ni les réponses pour améliorer ses produits. Je travaille depuis l'Espagne : le texte qui passe par mon outil n'entraîne donc pas Gemini.

Mais ne pas entraîner ne veut pas dire que la donnée disparaît, et c'est pourquoi l'avis demande toujours de ne pas saisir de données personnelles. Pour trois raisons :

  • Google l'enregistre un temps. Les mêmes conditions indiquent qu'il conserve prompts et réponses pendant une période limitée pour détecter les abus et répondre aux obligations légales. Le texte voyage jusqu'à ses serveurs et y est consigné.
  • Ma propre infrastructure conserve aussi. L'objectif, le contexte et le prompt généré sont gardés de façon anonyme jusqu'à 12 mois pour améliorer l'outil. Si quelqu'un y tape son numéro de pièce d'identité, il y reste. Chaque système par lequel passe un texte est un point de fuite de plus.
  • Certaines données ont leurs propres règles. Un nom associé à une allergie est déjà une donnée de santé, catégorie particulière au sens du RGPD. Un numéro de carte en clair relève de la norme PCI DSS. Une API d'IA généraliste n'est ni conçue ni certifiée pour servir de passerelle de paiement ou de dossier médical.

C'est exactement ce que devrait porter tout chatbot touristique, et presque aucun ne le fait : le client qui écrit à l'assistant d'un hôtel mérite de savoir que son texte est traité par la machine d'un tiers, et ce qu'il en advient.

4. Nommez le prestataire, pas votre architecture

Nuance apprise en rédigeant mes propres conditions : la réglementation exige d'identifier les entreprises qui traitent des données pour votre compte — elle n'exige pas de publier votre schéma technique. Dans ma politique, je nomme les prestataires et leur fonction (infrastructure technique, traitement du texte par IA), sans détailler versions ni configurations. Vous êtes conforme tout autant, et vous n'offrez pas gratuitement le plan de votre installation à qui en chercherait les coutures. Dans un secteur qui manie données de paiement et de voyage, cette pudeur technique est de l'hygiène de sécurité élémentaire.

5. Les données clients ne se collent jamais dans l'IA publique

La règle la plus importante est aussi la plus facile à enfreindre un mardi pressé : pas de noms, emails, réservations ou incidents de clients collés dans les versions publiques de ChatGPT, Gemini ou similaires. Ce faisant, vous perdez le contrôle de la donnée, qui peut finir utilisée pour l'entraînement — et aucun client ne vous a donné cette permission. Les guides du secteur hôtelier lui-même le disent désormais expressément (Cloudbeds, 2026). Travailler avec des données réelles exige des versions entreprise ou des API avec garanties contractuelles.

La solution opérationnelle est simple et bon marché : des gabarits anonymisés. « Rédige une réponse à un client qui se plaint du bruit dans la chambre X la nuit du jour Y » fonctionne aussi bien sans nom, sans email et sans numéro de réservation. C'est la même règle préalable qui ouvre les cinq étapes du plan marketing avec l'IA : des données réelles de l'entreprise, oui ; des données personnelles de clients dans des outils publics, jamais.

Le résumé honnête

Rien de tout cela n'a exigé d'avocats coûteux ni bloqué la moindre fonctionnalité : ce furent des décisions de conception prises à temps, presque toutes moins chères que leur alternative négligée. Voilà la lecture que j'offre à tout acteur touristique qui ajoute de l'IA : le RGPD n'est pas l'impôt payé à la fin du projet — c'est un ensemble de décisions de produit qui, prises au début, sont presque gratuites, et prises tard, coûtent une rénovation. Et dans un métier bâti sur la confiance de gens qui vous confient leur nom, leur carte et leurs dates de vacances, traiter les données avec ce soin n'est pas que de la conformité : c'est de la cohérence avec ce que vous vendez.

Questions fréquentes

Puis-je utiliser les données de mes clients avec ChatGPT ou Gemini ?

Pas dans leurs versions publiques : ne collez jamais de données personnelles de clients (noms, emails, données de réservation) dans des outils d'IA ouverts, car vous perdez le contrôle de cette donnée et elle peut servir à l'entraînement. Traiter des données réelles exige des versions entreprise ou des API avec les garanties contractuelles adéquates — et de le dire dans votre politique de confidentialité.

Un bandeau cookies suffit-il pour rendre mon analytique conforme ?

Seulement s'il bloque vraiment : les scripts de mesure ne doivent pas se charger avant l'acceptation, et refuser doit être aussi facile qu'accepter. Un bandeau qui décore pendant que les scripts chargent quand même n'est pas un consentement — c'est du décor.

Si mon site utilise l'IA pour traiter du texte, que dois-je annoncer ?

Trois choses, en langage clair, à côté de l'outil lui-même : que le texte est traité par un fournisseur d'IA (en le nommant), ce qui est conservé et pour combien de temps, et un avertissement de ne pas saisir de données personnelles ni confidentielles. Un avis court près du formulaire plus une page de conditions liée couvrent la double couche d'information.

Envie d'appliquer tout cela à votre activité ?

Écrivez-moi et nous en parlons, sans engagement. C'est moi qui réponds, pas un formulaire.

Discutons

Autres articles

Tourisme et technologie

Un agent d'IA peut-il lire votre site ? Checklist 7 points

Les robots des assistants d'IA n'exécutent pas JavaScript, les agents abandonnent devant les captchas et les formulaires longs, et le site d'un hôtel n'expose typiquement que 5 à 10 % de son information opérationnelle réelle. Cette checklist en 7 points permet de vérifier en un après-midi si votre site est lisible — et utilisable — par les IA qui recommandent déjà et commencent à réserver des voyages.

4 min de lecture

Lire l'article
Tourisme et technologie

Un site touristique en 5 langues sans plugins : les leçons

Un site multilingue bien fait a besoin de quatre choses qu'aucun plugin n'offre gratuitement : une URL propre par langue, des balises hreflang réciproques avec x-default, des slugs traduits décidés avant publication et une révision humaine des traductions. Je le raconte depuis un cas réel — mon propre site en espagnol, anglais, français, catalan et italien, servi en HTML statique avec un coût de maintenance proche de zéro.

5 min de lecture

Lire l'article
← Retour au blog