Protéger un livret numérique : URLs, indexation, cache et journaux

Cartographier avant de choisir une protection

Une règle unique comme « tout mettre en noindex » est insuffisante. Il faut d’abord identifier la surface, sa finalité, les personnes qui y accèdent et le lieu où une trace peut rester.

Qui est responsable de quoi ?

La confidentialité dépend d’une chaîne de responsabilités explicite. Un hébergeur ou un outil de mesure ne remplace pas la décision de l’émetteur sur les données nécessaires.

• L’émetteur du livret choisit les informations utiles, les corrige et détermine la période pendant laquelle le lecteur doit y accéder.
• Le moteur applicatif applique le contrôle d’accès, l’expiration, la révocation et la protection des actifs associés.
• Le lecteur protège le lien reçu, vérifie son contexte et utilise le canal de l’émetteur s’il détecte une erreur ou une divulgation.
• Le site-guide publie uniquement des explications générales ; il ne reçoit pas le lien privé, le contenu du livret ou une donnée de réservation.
• Une éventuelle conservation dans un compte constitue une action séparée, présentée avec sa finalité, sa durée et son retrait possible.

URLs : ne pas transformer une adresse en dossier de séjour

Une URL circule dans l’historique du navigateur, les captures, les outils de diagnostic, les en-têtes de référence et parfois les journaux intermédiaires. Elle ne doit donc contenir ni nom, ni coordonnées, ni dates de séjour, ni adresse d’hébergement, ni code d’accès, ni message d’hôte, ni contenu personnalisé.

Quand une référence est nécessaire, elle doit être opaque, limitée à la finalité annoncée, bornée dans le temps et révocable. Le serveur doit vérifier le droit d’accès ; la seule difficulté à deviner une adresse ne constitue pas un contrôle suffisant. Une redirection ou une page d’erreur ne doit pas recopier la référence dans du HTML public, une balise structurée ou un outil de mesure.

• Mauvais réflexe : former une URL avec un nom, une date ou un numéro de réservation compréhensible.
• Bon contrôle : vérifier côté service une référence opaque, son expiration et son état de révocation.
• Bon repli : afficher un message générique et orienter vers l’émetteur sans révéler si un séjour précis existe.
• Bon partage : transmettre le lien uniquement par le canal prévu et éviter sa copie sur un espace public.

Robots, noindex et sitemap ne sont pas des contrôles d’accès

Le protocole robots.txt donne des consignes aux robots d’exploration. La RFC 9309 précise que ces règles ne constituent pas une autorisation d’accès et que la liste de chemins peut elle-même rendre une structure visible. Une page privée doit donc être protégée au niveau applicatif, même si elle porte aussi une directive noindex.

Le sitemap et le maillage public ne doivent référencer que les guides généraux. Une page privée retirée du sitemap reste accessible à toute personne qui connaît son URL si aucun contrôle applicatif n’existe. À l’inverse, une réponse refusée ou expirée doit rester sûre même lorsqu’un robot ignore une consigne.

Cache : distinguer documentation publique et réponse personnalisée

Un guide général peut utiliser un cache public et une validation par ETag. Un livret ou un actif personnalisé ne doit jamais être placé dans un cache partagé faute d’une politique explicitement conçue pour empêcher qu’une réponse destinée à une personne soit resservie à une autre.

La RFC 9111 décrit le fonctionnement des caches HTTP ; elle ne décide pas à la place du service si une réponse contient une donnée privée. Pour un contenu authentifié ou personnalisé, une politique no-store ou un cache privé strictement borné est le point de départ prudent. La clé de cache, l’invalidation, l’expiration et le comportement hors ligne doivent être testés ensemble.

• Vérifier qu’un changement de lecteur ou de session ne réutilise jamais une réponse précédente.
• Ne pas précharger un livret privé depuis une page publique ou un service worker éditorial.
• Purger ou rendre inutilisable une référence révoquée sans attendre la fin d’un cache long.
• Conserver des actifs éditoriaux immuables sur des chemins versionnés, séparés des actifs de séjour.

Journaux et mesure : collecter assez pour sécuriser, pas assez pour reconstruire le séjour

La CNIL recommande de minimiser également les données de journalisation et de leur associer une durée de conservation. Un journal de sécurité peut consigner un résultat, une catégorie d’événement ou une référence technique protégée ; il ne doit pas dupliquer le contenu du livret, un code d’accès, un message ou une URL complète porteuse de données.

Les accès aux journaux doivent être restreints et leurs usages documentés. La mesure du site-guide reste agrégée et séparée : elle peut indiquer qu’un guide public a été consulté, mais pas quel séjour, quel hébergement ou quel livret une personne a ouvert.

Consultation, consentement et conservation sont trois décisions distinctes

Consulter un livret transmis pour un séjour ne signifie pas demander son ajout à un compte, ni accepter une mesure optionnelle. La conservation facultative dans My DOHM devra être proposée séparément dans une application qualifiée, avec une information compréhensible et une action positive.

La durée ne doit pas être choisie par habitude. La CNIL rappelle qu’elle dépend de la finalité et du cycle de vie des données. Refuser ou retirer une conservation ne doit pas bloquer la consultation encore légitime du livret ; inversement, la fin d’un séjour ou la révocation doit produire le comportement annoncé sans dépendre d’un bouton du site-guide.

Procédure en cas de lien exposé ou de contenu inattendu

Une suspicion doit d’abord limiter l’exposition, préserver les éléments techniques strictement nécessaires et rejoindre le responsable du traitement. Cette checklist est une méthode générale, pas un conseil juridique individuel.

1. Cesser de diffuser le lien et éviter de recopier son contenu dans un ticket, un e-mail collectif ou une capture publique.
2. Demander à l’émetteur ou au service compétent de révoquer l’accès concerné et de vérifier les actifs associés.
3. Consigner l’heure, le type d’exposition et les actions prises sans enrichir le journal avec les données touchées.
4. Évaluer avec le responsable compétent la nature des données, les personnes concernées et les conséquences possibles.
5. Appliquer la procédure de gestion des violations et les obligations éventuelles ; la CNIL fournit les repères officiels sur l’analyse et la notification.
6. Corriger la cause, vérifier les caches et les copies, puis documenter la prévention avant de rétablir un accès.

Checklist de qualification avant ouverture

• Le guide public, le moteur de livret et les actifs privés utilisent des origines ou des règles clairement séparées.
• Aucune donnée de séjour n’apparaît dans URL, HTML public, JSON-LD, analytics, message d’erreur ou cache partagé.
• Le droit d’accès, l’expiration et la révocation sont contrôlés par le service à chaque étape utile.
• robots.txt, noindex et absence du sitemap complètent le dispositif sans être présentés comme une protection.
• Les journaux sont minimisés, protégés, relus selon une finalité de sécurité et supprimés selon une durée documentée.
• Le refus de conservation, l’expiration, la révocation, l’erreur et le changement de lecteur ont chacun un test dédié.
• Le canal de correction est identifiable sans demander au lecteur de transmettre le contenu privé.
• La date de révision et les sources du guide public restent visibles.

Frontière actuelle de mydohm.com

mydohm.com publie ce guide, le catalogue des applications et les explications générales. Il ne reçoit, ne journalise et n’indexe aucune information de réservation, d’hébergement ou de séjour issue d’un livret.

État révisé le 25 août 2026 : la PWA catalogue My DOHM est publique et séparée du moteur de livrets. Le site-guide n’active ni création, ni conservation, ni transfert de livret. Une capacité future restera absente des CTA tant qu’une passation applicative fraîche n’aura pas qualifié son fonctionnement public.