Accord de sous-traitance de données personnelles (article 28 du RGPD)
Service : Staylo, logiciel de gestion hôtelière en ligne (PMS) Version : 2026-11-14-v2 · Date d'entrée en vigueur : [À COMPLÉTER : date de publication]
Entre les soussignés
Le Client, l'établissement qui a ouvert un compte Staylo. Son identité (raison sociale, forme juridique, SIRET, adresse, représentant, contact pour la protection des données) est celle qu'il renseigne dans son compte.
ci-après « le Responsable de traitement » ou « l'Hôtel »,
Et l'Éditeur, qui fournit le service Staylo : - Société : Hibook, raison sociale [À COMPLÉTER : raison sociale de Hibook] - Forme juridique, capital, SIREN, RCS : [À COMPLÉTER : forme juridique], [À COMPLÉTER : capital social], [À COMPLÉTER : SIREN], [À COMPLÉTER : ville du RCS] - Siège social : [À COMPLÉTER : adresse du siège] - Représentant : [À COMPLÉTER : nom et fonction du directeur de la publication] - Contact pour la protection des données : [À COMPLÉTER : e-mail dédié à la protection des données ou nom du référent]
ci-après « le Sous-traitant », « l'Éditeur » ou « Staylo » (l'Éditeur agit sous la marque Staylo).
1. Objet
Le présent accord encadre le traitement de données personnelles que Staylo réalise pour le compte de l'Hôtel, dans le cadre des conditions générales d'utilisation et de vente de Staylo (ci-après « le Contrat »). Il applique l'article 28 du règlement (UE) 2016/679 (RGPD).
Il ne concerne que les données des personnes dont l'Hôtel est responsable de traitement : voyageurs, accompagnants, prospects et contacts de l'Hôtel. Pour les données que l'Éditeur traite pour son propre compte (comptes des hôtels, demandes de démonstration, support, site vitrine), l'Éditeur est responsable de traitement et renvoie à sa politique de confidentialité. Dans ce document, « Staylo » désigne l'Éditeur Hibook agissant sous la marque Staylo.
En cas de contradiction entre le Contrat et le présent accord sur la protection des données, l'accord prévaut.
2. Durée
L'accord prend effet à la signature (ou à l'acceptation en ligne, voir l'article 16) et dure autant que le Contrat. Il se prolonge après la fin du Contrat pendant le temps nécessaire à la restitution et à la suppression des données (article 11).
3. Nature, finalités et durée du traitement
Staylo héberge et fait fonctionner le logiciel que l'Hôtel utilise pour gérer ses réservations, ses séjours, ses paiements, sa facturation, ses échanges avec les voyageurs et, selon l'offre souscrite, son site internet. La description détaillée figure en annexe A.
Le traitement se limite aux opérations que l'Hôtel déclenche en utilisant le service : collecte par les formulaires que l'Hôtel met en ligne, enregistrement, consultation, organisation, envoi de messages, calcul, export, conservation, effacement.
4. Instructions documentées
4.1. Staylo traite les données uniquement sur instruction documentée de l'Hôtel. Les instructions de l'Hôtel sont : le Contrat, le présent accord, les réglages que l'Hôtel choisit dans le service et ses demandes écrites au support.
4.2. Staylo n'utilise pas les données des voyageurs pour ses propres finalités : pas de prospection, pas de revente, pas d'entraînement de modèle d'intelligence artificielle, pas de profilage pour son compte.
4.3. Si Staylo estime qu'une instruction viole le RGPD ou une autre règle de protection des données, il en informe l'Hôtel sans délai. Il peut suspendre l'exécution de l'instruction concernée jusqu'à la réponse de l'Hôtel.
4.4. Si le droit de l'Union ou d'un État membre oblige Staylo à traiter les données autrement, il en informe l'Hôtel avant le traitement, sauf si la loi l'interdit.
5. Confidentialité du personnel
Staylo veille à ce que les personnes autorisées à traiter les données (salariés, associés, prestataires intervenant sur le service) soient tenues à la confidentialité par contrat ou par une obligation légale, et n'accèdent aux données que si leur mission l'exige. Les accès de l'équipe Staylo aux données d'un hôtel passent par une session de support ouverte avec un motif, limitée dans le temps par l'autorisation du Client et en lecture seule par défaut. Cette session est enregistrée dans le journal du Client.
Les personnes d'ADRD Consulting qui interviennent sur le service au titre de sa mission de développement et d'exploitation sont soumises aux mêmes règles (voir l'article 7.7).
Précision sur l'état actuel : depuis le 14/11/2026, la lecture des pièces d'identité est réservée au droit « identite » et chaque lecture est journalisée, et les exports de masse exigent une permission dédiée (annexe B, mesures M-12 et M-13, déployées en production le 14/11/2026). Le refus de ce droit et de cette permission pendant une session de support est à confirmer.
6. Sécurité
6.1. Staylo met en œuvre les mesures techniques et organisationnelles décrites en annexe B, adaptées au risque (article 32 du RGPD). L'annexe distingue ce qui existait avant le chantier du 13/11/2026 (en production, à confirmer), ce qui a été déployé en production le 14/11/2026, ce qui est déployé et activé le 14/11/2026 (la purge automatique ; aucun élément n'est aujourd'hui déployé sans être activé), ce qui est non fait ou non applicable à ce jour, ce qui est partiel (avec sa limite), ce qui est prévu (rien dans le code) et ce qui reste à décider, avec une échéance pour chaque mesure prévue.
6.2. Staylo peut faire évoluer ces mesures, à condition de ne pas diminuer le niveau de sécurité global. Toute évolution significative est reflétée dans l'annexe B mise à jour.
6.3. L'Hôtel reste responsable de la sécurité de ses propres accès : mots de passe des membres de son équipe, droits attribués à chacun, clés qu'il fournit lui-même (paiement, SMS, messagerie, intelligence artificielle).
7. Sous-traitants ultérieurs
7.1. Autorisation générale. L'Hôtel autorise Staylo à recourir aux sous-traitants ultérieurs listés en annexe C (version publiée sur la page Sous-traitants).
7.2. Information préalable de 30 jours. Staylo informe l'Hôtel de tout ajout ou remplacement d'un sous-traitant ultérieur au moins 30 jours avant que celui-ci ne reçoive des données de l'Hôtel. L'information se fait par e-mail à l'adresse du contact de l'Hôtel, et par mise à jour de la page publique avec sa date.
7.3. Droit d'opposition. L'Hôtel peut s'opposer au changement, par écrit et pour un motif raisonnable lié à la protection des données, dans les 30 jours suivant l'information. Les parties cherchent d'abord une solution : désactivation de la fonction concernée pour cet hôtel, alternative, ou aménagement. Si aucune solution n'est trouvée, l'Hôtel peut résilier le Contrat pour la partie concernée sans pénalité, avec remboursement au prorata de la période non utilisée.
7.4. Obligations transmises. Staylo impose à chaque sous-traitant ultérieur des obligations de protection au moins équivalentes à celles du présent accord, par contrat. Staylo reste responsable envers l'Hôtel de l'exécution des obligations de ses sous-traitants ultérieurs.
7.5. Services choisis par l'Hôtel avec ses propres comptes. Plusieurs services de l'annexe C ne fonctionnent qu'avec un compte ou une clé que l'Hôtel a lui-même ouvert (paiement par carte, prélèvement SEPA, SMS, WhatsApp, channel manager, intelligence artificielle, serveur d'e-mails). Dans ce cas, l'Hôtel conclut son propre contrat avec le fournisseur, et Staylo n'agit que comme outil technique de transmission. L'annexe C indique, pour chaque service, de quel cas il s'agit. L'Hôtel peut désactiver chacun de ces services dans ses réglages.
7.6. Partenaires d'intégration. Lorsque l'Hôtel active une clé d'API ou un webhook au profit d'un partenaire (outil comptable, gestionnaire de canaux, CRM), ce partenaire est choisi et contractualisé par l'Hôtel. Staylo n'est pas son sous-traitant et n'en répond pas, sauf si le partenaire a été mis à disposition par Staylo et figure en annexe C.
7.7. ADRD Consulting, prestataire de développement et d'exploitation. L'Éditeur confie à ADRD Consulting le développement, la maintenance et l'exploitation technique du service (accès à l'administration, aux sauvegardes et au support). ADRD Consulting est donc un sous-traitant ultérieur de l'Éditeur et figure en annexe C. Un accord de sous-traitance conforme à l'article 28 est conclu entre l'Éditeur et ADRD Consulting (modèle : document « 13-DPA-hibook-adrd ») ; il impose à ADRD Consulting les obligations du présent accord. [À COMPLÉTER : date de signature de l'accord interne, à faire après l'immatriculation d'Hibook ; liens éventuels entre les deux sociétés à faire examiner par l'avocat.]
8. Assistance pour l'exercice des droits des personnes
8.1. Si une personne s'adresse directement à Staylo pour exercer un droit sur des données dont l'Hôtel est responsable, Staylo ne répond pas sur le fond. Il transmet la demande à l'Hôtel dans les 5 jours ouvrés et en informe la personne.
8.2. Staylo aide l'Hôtel, par des moyens techniques appropriés, à répondre aux demandes d'accès, de rectification, d'effacement, de limitation, de portabilité et d'opposition. La procédure détaillée est dans le document « Procédure d'exercice des droits des personnes ».
8.3. État de l'outillage. L'Hôtel peut exporter et effacer les données d'une personne depuis les réglages et la fiche client. Dans la version déployée en production le 14/11/2026, ces fonctions couvrent les 44 sources déclarées au registre de l'application (fiche client, réservations et accompagnants, check-in, messages du Hub, enquêtes, avis, formulaires, newsletter, historique des consentements, quarantaine IMAP, cautions, SEPA, brouillons IA, demandes de droits, etc.), la personne peut aussi déposer sa demande en ligne (page publique par hôtel, lien de confirmation à usage unique valable 2 heures), et les effacements sont rejoués après la restauration d'une sauvegarde (annexe B, mesures M-07, M-07b et M-10). Pour toute donnée qui ne serait pas couverte par l'outillage, Staylo exécute l'opération sur demande écrite de l'Hôtel, dans un délai de 10 jours ouvrés [À COMPLÉTER : délai à confirmer par Allan, il doit rester compatible avec le délai d'un mois imposé à l'Hôtel]. Limites connues, y compris après déploiement : les sauvegardes existantes ne sont pas modifiées (l'effacement n'y devient effectif qu'à la fin de la rotation de 30 jours) ; les copies hors application (anciens instantanés) ne sont pas traitées ; les informations de santé écrites en texte libre ne sont pas détectées par leur contenu ; les factures et avoirs gardent le nom et l'adresse de l'acheteur pendant 10 ans (mentions obligatoires). Décision à prendre (document 12, D6) : dans le code déployé, une demande d'effacement supprime aussi la preuve du contrat (nom du check-in, signature, adresse IP de signature) avant l'échéance de 5 ans.
9. Assistance pour la sécurité, l'analyse d'impact et la consultation préalable
Staylo aide l'Hôtel à respecter les articles 32 à 36 du RGPD, compte tenu de la nature du traitement et des informations dont il dispose. Il fournit notamment, sur demande : la description des mesures de sécurité, l'analyse d'impact de Staylo (document « AIPD Staylo »), le registre de ses traitements pour le compte de l'Hôtel, et les éléments nécessaires à une éventuelle consultation de la CNIL.
10. Notification des violations de données
10.1. Staylo notifie l'Hôtel de toute violation de données personnelles touchant ses données sans retard injustifié et au plus tard 48 heures après en avoir pris connaissance. Le délai de 72 heures de l'article 33 court pour l'Hôtel dès qu'il en est informé : Staylo n'attend donc pas d'avoir toutes les informations pour prévenir.
10.2. La notification est envoyée au contact de l'Hôtel indiqué ci-dessus et contient, dans la mesure du possible : la nature de la violation, les catégories et le nombre approximatif de personnes et de fiches concernées, les conséquences probables, les mesures prises ou proposées, et un point de contact. Staylo complète ensuite l'information par étapes.
10.3. Staylo tient un registre de ses violations, aide l'Hôtel à notifier la CNIL et, si nécessaire, les personnes concernées, et ne communique pas lui-même auprès de la CNIL ou des personnes au nom de l'Hôtel sans son accord, sauf obligation légale.
10.4. La procédure interne de Staylo figure dans le document « Procédure de violation de données ».
11. Fin du Contrat : restitution et suppression
11.1. Export. À la fin du Contrat, quelle qu'en soit la cause, Staylo met à disposition de l'Hôtel un export de ses données dans un format structuré et lisible par machine (fichiers JSON ou CSV) [À COMPLÉTER : confirmer les formats livrés]. L'Hôtel dispose de 30 jours après la date de fin pour récupérer cet export.
11.2. Suppression. À l'issue de ces 30 jours, Staylo supprime les données de l'Hôtel de son environnement de production sous 30 jours, sauf obligation légale de conservation. Les copies de sauvegarde sont purgées par rotation dans la limite de 30 jours supplémentaires. Staylo confirme la suppression par écrit sur demande.
11.3. Pièces comptables. Les factures et avoirs émis par l'Hôtel doivent être conservés par lui pendant 10 ans. L'Hôtel doit donc récupérer son export avant la suppression. Staylo n'est pas tenu de conserver ces pièces pour l'Hôtel au-delà du délai de l'article 11.2.
11.4. Point à ne pas oublier : le fonctionnement actuel du service place un hôtel supprimé en corbeille pendant 30 jours puis efface toutes ses données, factures comprises, et ne produit pas d'export automatique. L'export de fin de contrat est donc une mesure prévue, sans rien dans le code (annexe B, mesure M-09) ; d'ici là, Staylo le prépare à la main sur demande de l'Hôtel.
11.5. Staylo conserve ce que la loi l'oblige à garder pour ses propres besoins (factures d'abonnement, 10 ans) et, de façon limitée, les éléments nécessaires à la preuve de l'exécution du Contrat. Ces éléments ne contiennent pas de données de voyageurs.
12. Audit
12.1. Staylo met à disposition de l'Hôtel les informations nécessaires pour démontrer le respect du présent accord.
12.2. L'Hôtel peut faire réaliser un audit, par lui-même ou par un auditeur indépendant tenu au secret, au maximum une fois par an, sauf après une violation avérée ou à la demande d'une autorité. Il prévient Staylo au moins 30 jours à l'avance, définit avec lui le périmètre et la durée, et ne perturbe pas le service ni les autres clients. Les données des autres clients et les secrets de Staylo restent hors périmètre. Les frais de l'audit sont à la charge de l'Hôtel, sauf si l'audit révèle un manquement grave de Staylo.
12.3. Staylo peut proposer, à la place d'un audit sur place, un rapport d'audit récent établi par un tiers indépendant, s'il en dispose [À COMPLÉTER : à ce jour, aucun rapport tiers n'existe].
13. Transferts de données hors de l'Union européenne
13.1. Staylo n'exporte pas volontairement de données hors de l'Union européenne. Certains sous-traitants ultérieurs de l'annexe C peuvent toutefois traiter des données hors de l'Espace économique européen, notamment aux États-Unis.
13.2. Pour ces transferts, Staylo s'assure qu'un mécanisme de l'article 45 ou 46 du RGPD s'applique : décision d'adéquation (dont le Data Privacy Framework pour les entreprises américaines certifiées), ou clauses contractuelles types de la Commission européenne, complétées si besoin de mesures supplémentaires. L'annexe C indique, pour chaque fournisseur, le mécanisme à confirmer : aucune base de transfert n'est affirmée tant qu'elle n'a pas été vérifiée dans les documents du fournisseur.
13.3. Pour les services que l'Hôtel active avec son propre compte (article 7.5), le mécanisme de transfert relève du contrat entre l'Hôtel et le fournisseur.
14. Responsabilité
14.1. Chaque partie répond de ses manquements à ses obligations de protection des données, dans les conditions du RGPD (article 82) et du droit applicable.
14.2. Dans leurs relations, la responsabilité de Staylo au titre du présent accord est plafonnée au montant des sommes versées par l'Hôtel au titre du Contrat durant les [À COMPLÉTER : 12] derniers mois, sauf faute lourde, dol, ou dommage qui ne peut être limité par la loi [À COMPLÉTER : plafond à faire valider par l'avocat].
14.3. L'Hôtel garantit Staylo contre les réclamations de tiers qui résulteraient d'une instruction illicite de sa part ou d'un défaut d'information des personnes dont il est responsable.
15. Rôles de chaque partie, rappel
| Sujet | L'Hôtel (responsable) | Staylo (sous-traitant) |
|---|---|---|
| Base légale, finalités, durées | Décide et documente | Applique les durées par défaut décrites en annexe A et les réglages de l'Hôtel |
| Information des voyageurs | Rédige et publie sa politique de confidentialité | Fournit un modèle (document « Modèle de politique de confidentialité hôtel ») |
| Droits des personnes | Répond dans le mois | Aide, exécute les opérations techniques |
| Pièce d'identité et fiche de police | Décide s'il les demande (pièce facultative par défaut) et fixe la durée (pièce : 0 à 90 jours ; fiche de police : 30 à 365 jours, après avis de son conseil sur l'obligation légale) | Fournit l'outil, supprime à l'échéance |
| Registre des traitements | Tient le sien | Tient le registre des traitements faits pour l'Hôtel |
| Violation | Notifie la CNIL (72 h) et les personnes | Prévient l'Hôtel (au plus tard 48 h) et aide |
16. Conclusion, modification, droit applicable
16.1. Conclusion. L'accord est conclu par signature électronique du Super Admin de l'Hôtel, dans l'administration de Staylo : le signataire dessine sa signature, indique son nom et sa fonction, confirme qu'il a lu l'accord et qu'il peut engager l'Hôtel, et s'authentifie (code de double authentification, sinon mot de passe). Sont conservés avec la fiche de l'Hôtel : la date et l'heure fixées par le serveur, la version du texte, l'empreinte SHA-256 du contenu, le compte et l'identité déclarée du signataire, l'image de la signature, une adresse IP hachée (jamais l'adresse elle-même) et un exemplaire PDF signé, que l'Hôtel peut télécharger à tout moment. Il s'agit d'une signature électronique simple : elle ne peut être refusée au seul motif qu'elle est électronique (règlement (UE) n° 910/2014, article 25). La case cochée à l'inscription est conservée comme preuve de l'acceptation initiale mais ne dispense pas de cette signature. L'accord peut aussi être signé sur demande, sur papier ou par un autre procédé.
16.2. Modification. Staylo peut modifier l'accord pour suivre la loi ou le service, avec un préavis de 30 jours par e-mail. L'Hôtel qui refuse peut résilier sans pénalité avant l'entrée en vigueur.
16.3. Droit applicable et tribunal. Droit français. [À COMPLÉTER : tribunal compétent, à valider par l'avocat avec les CGU/CGV].
Annexe A : description du traitement
A.1. Personnes concernées
- Voyageurs ayant réservé ou séjourné chez l'Hôtel (titulaires de réservation).
- Accompagnants (nom et âge, saisis par le personnel de l'Hôtel).
- Contacts et clients de l'Hôtel (fiche client, abonnés à la newsletter, répondants aux formulaires, enquêtes et avis).
- Membres du personnel de l'Hôtel (comptes, journal d'audit). Pour leurs données de compte, voir aussi la politique de confidentialité de l'Éditeur : l'Éditeur est alors responsable de traitement des identifiants de connexion.
- Techniciens et prestataires que l'Hôtel enregistre dans le module de maintenance (nom, société).
A.2. Catégories de données
| Catégorie | Données | Remarque |
|---|---|---|
| Identité et contact | Nom, prénom, e-mail, téléphone, langue, préférences de chambre | |
| Réservation | Dates, chambre, nombre de voyageurs, source, montants, message libre du voyageur | Le message libre peut contenir des informations de santé ou de handicap que le voyageur y écrit ; un avertissement « pas d'informations de santé » est affiché sous les champs libres du check-in (livré le 13/11/2026 ; déploiement en production à confirmer), mais pas encore sur tous les formulaires |
| Check-in en ligne | Nom complet, date de naissance et adresse (facultatives), copie de la pièce d'identité (image ou PDF) selon le réglage de l'Hôtel (par défaut : facultative ; réglable en « encouragée » ou « exigée des seuls clients hors Union européenne, EEE et Suisse », contrôle fait côté serveur), signature du contrat, adresse IP de signature, code de porte (affiché seulement dans le créneau d'arrivée) | La pièce d'identité est une donnée à risque élevé, mais pas une donnée sensible au sens de l'article 9. Les fichiers de pièce d'identité téléversés depuis le 14/11/2026 sont chiffrés au repos, ainsi que la fiche de police (déployé en production le 14/11/2026 ; voir M-14 pour la limite sur la clé) ; le chiffrement au repos du nom, de la naissance, de l'adresse, de l'IP de signature et des fichiers de signature est à confirmer. Les pièces d'identité déjà stockées avant le 14/11/2026 ne sont pas encore chiffrées (outil de migration non exécuté). Le réglage « pièce d'identité facultative » est propre à chaque hôtel : la valeur des hôtels existants n'a pas été modifiée le 14/11/2026, et le comportement de chacun (pièce demandée à tous ou facultative) est à confirmer hôtel par hôtel |
| Fiche de police | Seulement si l'Hôtel active l'option et si le voyageur déclare une nationalité hors UE, EEE et Suisse : nom, prénoms, date et lieu de naissance, nationalité, domicile, type et numéro du document | Désactivée par défaut. Stockée chiffrée, séparément de la copie de la pièce. La nationalité elle-même n'est pas conservée en dehors de cette fiche (seul le groupe « UE » ou « hors UE » l'est). Base légale et durée à faire confirmer par l'avocat |
| Accompagnants | Nom et âge (le nom est vidé pour un voyageur de moins de 18 ans : seul l'âge est gardé) | L'âge sert au calcul de la taxe de séjour |
| Santé (potentielle) | Allergies et restrictions déclarées (fiche client) ; notes de ménage signalées comme sensibles | Donnée sensible (art. 9). Allergies : case de consentement explicite horodatée (date et source), refus d'enregistrer sans la case, lecture réservée au droit « identite » (déployé en production le 14/11/2026 pour la lecture réservée ; case de consentement et horodatage : déploiement à confirmer). Notes de ménage : détection par mots (allergie, régime, halal, PMR, grossesse…) et case « note sensible » ; la détection est un indice, pas une preuve |
| Paiement | Montants, références de transaction, e-mail du payeur, références de mandat SEPA. Les numéros de carte ne passent jamais par Staylo | |
| Facturation | Factures et avoirs avec identité de l'acheteur figée | |
| Communications | Conversations et messages (e-mail, SMS, WhatsApp, portail), notes internes ; copies de la boîte e-mail reçue (si l'Hôtel active la relève) pour les seuls expéditeurs rattachés à une fiche client ou à une réservation ; quarantaine sans contenu pour les autres (empreinte HMAC de l'expéditeur, date, objet tronqué à 60 caractères) | Le droit de lecture du Hub est distinct (communication_lire) |
| Marketing et consentement | Consentement par canal (e-mail, SMS, WhatsApp) avec preuve (date, source, version du texte, auteur, empreinte HMAC de l'adresse IP) ; historique des consentements, désinscriptions et oppositions (consent_log) ; liste de suppression ; file d'envoi ; événements d'ouverture et de clic |
Suivi d'ouverture et de clic désactivé par défaut (déployé en production le 14/11/2026) ; événements agrégés, sans lien avec la personne, tant qu'elle n'a pas donné un accord de suivi distinct |
| Retours | Réponses d'enquête (lien valable 90 jours après l'envoi), avis, réponses aux formulaires | |
| Droits des personnes | Demandes déposées en ligne (gdpr_requests : e-mail jusqu'au traitement, puis empreinte) ; registre des effacements (gdpr_erasures : empreintes HMAC de l'e-mail, hôtel, date, sources) |
Aucune donnée en clair dans le registre des effacements |
| Intégrations et export | Jeton de l'export iCal (256 bits, conservé haché, un par chambre et un par hôtel) ; autorisation donnée à un partenaire (niveau de données, date, compte de l'équipe qui a autorisé) ; journal des envois aux partenaires (contenu gardé 48 h pour les seuls envois échoués) | Les événements « Réservé » de l'export iCal ne portent aucun nom |
| Comptes de l'équipe de l'Hôtel (données dont l'Éditeur est responsable) | E-mail, nom, mot de passe haché, secret TOTP chiffré (double authentification), appareils mobiles (libellé, dates), empreinte HMAC des adresses de connexion connues | Voir la politique de confidentialité de l'Éditeur |
| Traces techniques | Journal d'audit de l'Hôtel (e-mail du compte de l'équipe ; jamais d'adresse ni de nom de client : « client #id »), journal d'audit chaîné par empreinte, journal de connexion (e-mail saisi remplacé par une empreinte HMAC pour un compte inconnu), alertes de sécurité, registre des violations (data_breaches) |
Chaînage du journal d'audit et registre des violations : déployés en production le 14/11/2026 ; alertes de sécurité : déploiement à confirmer (l'envoi réel d'alertes Telegram ou e-mail n'a pas été testé) |
A.3. Opérations et finalités (pour le compte de l'Hôtel)
Gestion des réservations et du planning · check-in en ligne et contrat · encaissement et facturation · communication avec les voyageurs · newsletter et prospection (si l'Hôtel l'active) · enquêtes et avis · taxe de séjour · site internet de l'Hôtel (selon l'offre) · intégrations choisies par l'Hôtel · réception et traitement des demandes d'exercice des droits des personnes.
A.4. Durées de conservation par défaut
Ces durées sont celles du registre unique de l'application (includes/gdpr-registry.php, 30 règles de durée). L'Hôtel, responsable de traitement, doit les valider ; il peut les régler entre le plancher et le plafond indiqués, dans Paramètres, section « Conservation des données ». La purge automatique est déployée et activée le 14/11/2026 (fichier includes/data/.retention-armed posé après validation) : ces durées sont appliquées automatiquement chaque nuit, de 2 h à 6 h, au premier passage du planificateur. Le premier passage réel n'a pas encore eu lieu à la date de cette mise à jour ; la simulation du 14/11/2026 sur les données réelles a compté 4 éléments (3 copies de pièces d'identité orphelines et 1 jeton expiré). Les factures et avoirs ne sont jamais supprimés. Durées chiffrées du tableau ci-dessous : durées arrêtées par Allan Dorvilma (Hibook) le 14/11/2026 (tableau reproduit en annexe du document 07) ; les bases légales restent à confirmer par l'avocat. Deux écarts avec ce tableau, écrits honnêtement : (1) l'âge des accompagnants nécessaire à la taxe de séjour n'a pas de durée propre (statut « Décision à prendre : durée légale à fixer ») ; (2) « archivage puis suppression » (preuve du contrat, SEPA) : l'application pseudonymise sans créer d'archive séparée (statut « Partiel »).
| Donnée | Durée par défaut (plancher / plafond) | Point de départ | Statut de déploiement |
|---|---|---|---|
| Pièce d'identité (fichier) | 7 jours (0 / 90) | Départ | Déployée et activée le 14/11/2026 (avant le chantier : 90 jours par défaut, sans purge de secours en cas de réservation supprimée ; le comportement réel actuel est à confirmer). Suppression anticipée possible : bouton « Pièce vérifiée » |
| Date de naissance et adresse du check-in | 90 jours (7 / 365) | Départ | Déployée et activée le 14/11/2026 (avant le chantier : 180 jours ; le comportement réel actuel est à confirmer) |
| Preuve du contrat (nom, signature, contrat accepté, IP de signature) | 5 ans (1 an / 5 ans) | Départ | Déployée et activée le 14/11/2026 (avant l'activation du 14/11/2026, conservée sans limite). Une demande d'effacement la supprime avant l'échéance : décision à prendre (document 12, D6). Durée arrêtée par Allan Dorvilma (Hibook) le 14/11/2026 (archivage puis suppression). Partiel : l'application pseudonymise (nom rendu anonyme, signature et IP supprimées) et ne crée pas d'archive séparée |
| Fiche de police (hors UE, EEE, Suisse ; si l'option est active) | 183 jours (30 / 365) | Départ | Déployée et activée le 14/11/2026. Durée arrêtée par Allan Dorvilma (Hibook) le 14/11/2026 ; base légale à confirmer par l'avocat |
| Allergies | 30 jours (0 / 365) | Dernier séjour | Déployée et activée le 14/11/2026 |
| Accompagnants (noms ; l'âge est gardé pour la taxe) | 30 jours (0 / 365) pour les noms ; durée de l'âge : durée légale applicable à la taxe de séjour, à partir de la fin de l'obligation, puis suppression (non chiffrée) | Départ | Noms : déployée et activée le 14/11/2026, durée arrêtée par Allan Dorvilma (Hibook) le 14/11/2026. Âge : Décision à prendre : durée légale à fixer (l'application conserve l'âge dans la réservation jusqu'à son anonymisation à 3 ans ; aucune règle propre) |
| Réservations et fiches clients, rendues anonymes | 3 ans (1 an / 10 ans) | Dernier séjour | Déployée et activée le 14/11/2026 |
| Factures, avoirs, encaissements | 10 ans, jamais purgés | Émission | Conservation existante avant le chantier. Le nom et l'adresse de l'acheteur sont des mentions obligatoires de la facture : ils sont conservés (accès restreint à la comptabilité) et la réservation liée est anonymisée. Choix à faire valider par l'avocat |
| Messages et conversations du Hub | 24 mois (90 jours / 36 mois) | Dernier message | Déployée et activée le 14/11/2026 |
| Copies de la boîte e-mail reçue (IMAP) | 90 jours (7 / 365) | Réception | Déployée et activée le 14/11/2026 |
| Quarantaine IMAP (expéditeurs inconnus : empreinte, date, objet tronqué) | 30 jours (7 / 30) | Réception | Déployée et activée le 14/11/2026 |
| Enquêtes et avis | 24 mois (90 jours / 36 mois) | Réponse | Déployée et activée le 14/11/2026. Le lien d'enquête expire 90 jours après l'envoi (réglable de 7 à 365 jours) |
| Réponses aux formulaires | 12 mois (30 jours / 730 jours) | Envoi | Déployée et activée le 14/11/2026 |
| Preuve des consentements et désinscriptions (historique) | 5 ans (1 an / 5 ans) | Événement | Déployée et activée le 14/11/2026 |
| Événements de suivi de la newsletter | 13 mois (30 / 730 jours) | Événement | Déployée et activée le 14/11/2026 |
| File d'envoi de la newsletter | 12 mois (30 / 730 jours) | Envoi | Déployée et activée le 14/11/2026 |
| Liste de suppression de la newsletter | Conservée : obligation d'honorer l'opposition ; l'effacement d'une personne l'y inscrit | Déployée en production le 14/11/2026 | |
| Exécutions de scénarios automatiques | 12 mois (30 / 730 jours) | Exécution | Déployée et activée le 14/11/2026 |
| Brouillons de l'agent IA | 90 jours (7 / 365) | Création | Déployée et activée le 14/11/2026 |
| Cautions et liens de paiement | 24 mois (90 jours / 5 ans) | Création | Déployée et activée le 14/11/2026 |
| Mandats et prélèvements SEPA | 36 mois (395 jours / 10 ans) | Dernier prélèvement | Déployée et activée le 14/11/2026. Durée arrêtée par Allan Dorvilma (Hibook) le 14/11/2026 (archivage puis suppression). Partiel : l'application pseudonymise et ne crée pas d'archive séparée |
| Notes de ménage et de planning | 90 jours (7 / 365) | Note | Déployée et activée le 14/11/2026 |
| Journal d'audit de l'hôtel | 12 mois (90 jours / 36 mois) | Action | Déployée et activée le 14/11/2026 (le plafond en nombre de lignes existait avant l'activation : à confirmer) |
| Journaux de connexion | 12 mois (90 / 365 jours) | Connexion | Déployée et activée le 14/11/2026 (le plafond en nombre de lignes existait avant l'activation : à confirmer) |
| Demandes de démonstration (prospects de l'Éditeur) | 3 ans (180 jours / 3 ans) | Dernier contact | Déployée et activée le 14/11/2026 |
| Tickets de support clos | 24 mois (90 jours / 36 mois) | Dernière activité | Déployée et activée le 14/11/2026 |
| Jetons expirés (compte, formulaire, lien) | 30 jours (7 / 90) | Expiration | Déployée et activée le 14/11/2026 |
| Jetons mobiles expirés | 0 jour (0 / 30) ; un jeton vaut 90 jours au plus, sans prolongation | Expiration | Déployée et activée le 14/11/2026 |
Copies de repli .bak et .corrupt-* |
30 jours (7 / 90) | Création | Déployée et activée le 14/11/2026 |
| Corbeille d'un hôtel supprimé | 30 jours (7 / 90) | Suppression | Déployée et activée le 14/11/2026 |
| Demandes d'exercice des droits traitées | 36 mois (12 mois / 60 mois) | Traitement | Déployée et activée le 14/11/2026 |
| Registre des effacements (empreintes) | 24 mois (90 jours / 60 mois) | Effacement | Déployée et activée le 14/11/2026 |
| Journal des envois aux partenaires | 14 jours ; contenu des envois échoués : 48 heures | Envoi | Déployée et activée le 14/11/2026 (purge à chaque écriture : à confirmer) |
| Empreintes des adresses de connexion connues (comptes de l'équipe) | 12 mois | Connexion | Déployée et activée le 14/11/2026 (purge à chaque écriture : à confirmer) |
| Alertes de sécurité | Les 500 dernières (limite en nombre, non en durée) | Déployée le 14/11/2026 (envoi réel des alertes non testé). Durée à confirmer | |
| Registre des violations | [À COMPLÉTER : durée à fixer avec l'avocat] | Déployé en production le 14/11/2026 | |
| Sauvegardes | 30 jours | Création | Existante avant le chantier (rotation réelle à confirmer). Une purge ne modifie pas les sauvegardes existantes : l'effacement y devient effectif à la fin de la rotation, d'où le rejeu des effacements après toute restauration |
Les données de santé écrites en texte libre (message du voyageur, commentaire d'enquête) ne sont pas détectées par leur contenu : elles sont couvertes par les durées ci-dessus, pas par une détection automatique.
A.5. Lieu et support du traitement
Les données sont enregistrées dans une base de données MySQL (moteur de référence ; les essais ont été faits sur MariaDB 13.0.2, pas sur MySQL 8) et dans des fichiers (pièces d'identité, signatures, documents, et les modules qui n'ont pas de table : newsletter, formulaires, scénarios, cautions, SEPA, avis, notes de ménage, tickets de support, jetons mobiles, partenaires) sur le même hébergement. Les sauvegardes doivent donc inclure les fichiers de données en plus de la base. Au 14/11/2026, la production fonctionne avec le moteur JSON (fichiers) sur l'hébergement mutualisé Hostinger ; MySQL ne sera utilisé qu'après la bascule prévue sur le VPS (migrations SQL 04 à 09 non applicables d'ici là).
Les clés de chiffrement (.checkin-key pour le check-in, .encryption-key pour les secrets) sont stockées par défaut sur le même serveur que les données, dans includes/data/ ; la recommandation est de définir la constante CHECKIN_KEY_FILE vers un chemin hors de la racine web. Tant que ce n'est pas fait, un attaquant qui lit le disque lit les données et la clé.
Hébergement : Hostinger [À COMPLÉTER : mutualisé ou VPS, localisation du centre de données au jour de la signature]. Voir l'annexe C pour les autres lieux.
Annexe B : mesures de sécurité
Vocabulaire des deux colonnes d'état.
Colonne « Livraison » : Existant = mesure présente dans le code d'avant le chantier du 13/11/2026 ; Livré = codé et testé en local le 13/11/2026 (lots A à E), puis mis en ligne pour la plupart des mesures le 14/11/2026 (voir la colonne de déploiement), sans limite connue autre que celles de la dernière colonne ; Partiel = livré en partie, la limite précise est dans la dernière colonne ; Prévu = rien dans le code ; Décision à prendre = le code existe mais le choix revient à Allan ou à l'avocat.
Colonne « Statut de déploiement » : En production avant le chantier (à confirmer) = présent dans le code d'avant ; à confirmer par comparaison avec le serveur, car le code de la démonstration et de la production diverge du dépôt. Déployé en production le 14/11/2026 = en ligne sur staylo.group-adrd.com (moteur JSON, hébergement mutualisé Hostinger). Déployé et activé le 14/11/2026 = le code est en ligne et la mesure agit (purge automatique de conservation, activée le 14/11/2026). La catégorie « déployé, non activé » (code en ligne sans effet) n'a plus d'élément à ce jour. Partiel = en partie seulement, la limite est précisée. Prévu = rien dans le code ou rien en ligne. Décision à prendre = le choix revient à Allan ou à l'avocat. Non fait ou non applicable = voir la mention (par exemple migrations SQL 04 à 09, réservées à la bascule MySQL sur le VPS). Quand le statut est « à confirmer », la mesure ne doit pas être présentée comme en place. Ce document ne doit être ni publié ni signé tant que les mesures qu'il annonce ne sont pas toutes confirmées.
Tous les tests ont été faits sur des copies locales (MariaDB 13.0.2 et stockage en fichiers) avant la mise en ligne du 14/11/2026, jamais sur la production ; aucun fournisseur réel n'a été appelé (paiement, SMS, IA, e-mail, Telegram) ; Apache et nginx n'ont pas été essayés.
B.1. Accès et authentification
| Réf. | Mesure | Livraison | Statut de déploiement | Limites, décisions, échéance |
|---|---|---|---|---|
| M-01 | Mots de passe stockés avec bcrypt (coût 12) | Existant | En production avant le chantier (à confirmer) | |
| M-02 | Limitation des tentatives de connexion côté serveur (par adresse IP, par identifiant et par paire) | Existant | En production avant le chantier (à confirmer) | |
| M-03 | Protection contre le vol de session : renouvellement de l'identifiant à la connexion, fin des sessions après changement de mot de passe | Existant | En production avant le chantier (à confirmer) | |
| M-04 | Jeton de protection (CSRF) sur toutes les actions des pages d'administration, et contrôle de connexion avant tout traitement | Existant | En production avant le chantier (à confirmer) | |
| M-05 | Cloisonnement des hôtels : un utilisateur ne voit que les hôtels auxquels il est rattaché | Existant | En production avant le chantier (à confirmer) | En mode MySQL, le pseudo-hôtel _new (nécessaire à la page de connexion) existe toujours en base ; en mode fichiers, l'écriture sans hôtel est refusée et journalisée |
| M-06 | Double authentification TOTP (RFC 6238) : obligatoire pour tous les comptes de la plateforme (enrôlement avant tout accès) et pour les administrateurs d'hôtel (Paramètres ou Utilisateurs), sans délai de grâce depuis le 14/11/2026 (réglage mfa_grace_days à 0 ; délai réglable de 0 à 90 jours dans le code) ; facultative pour les autres rôles. Secret TOTP chiffré, anti-rejeu, 6 codes faux = verrou du compte 15 minutes, 30 essais par adresse IP, alerte au verrouillage |
Livré | Déployé en production le 14/11/2026 | Aucun code de secours : un compte dont l'appareil est perdu est réinitialisé par un autre propriétaire de la plateforme (journal, e-mail au titulaire) ou en ligne de commande sur le serveur (tools/mfa-reset.php) ; les comptes protégés ne se réinitialisent qu'en ligne de commande. Au déploiement, tout compte plateforme et toute session plateforme ouverte sont coupés jusqu'à l'enrôlement (risque de verrouillage : deux propriétaires au moins). Décision à prendre : confirmer le délai de grâce nul et l'absence de codes de secours |
| M-06b | Jetons de réinitialisation de mot de passe (1 h pour un lien renvoyé, 48 h pour une invitation) et de vérification d'e-mail (24 h) stockés hachés (SHA-256), comparés en temps constant, à usage unique ; ancien format refusé ; suppression des anciennes lignes en clair prévue (migration 09 en MySQL, tools/rgpd-purge-clear-tokens.php en fichiers), non faite à ce jour |
Livré | Déployé en production le 14/11/2026 | Le jeton d'enquête n'est pas concerné : voir M-06f. Nettoyage des anciens jetons en clair non exécuté (tools/rgpd-purge-clear-tokens.php non exécuté ; migration 09 non applicable tant que la production est en JSON) |
| M-06c | Paramètres de cookie de session communs (HttpOnly, SameSite=Lax, Secure forcé en production par la variable STAYLO_ENV) sur tous les points d'entrée ; durées d'inactivité et durées absolues de session par type de compte (voir docs/SECURITE.md) ; régénération à la connexion, au second facteur et à l'ouverture d'une session de support |
Livré | Livré le 13/11/2026 ; déploiement en production à confirmer (non listé parmi les mesures confirmées en ligne le 14/11/2026) | |
| M-06d | Politique de mot de passe : 12 caractères au moins, 72 octets au plus, refus des mots de passe courants (liste locale de 41 486 entrées et variantes), des suites et de l'adresse e-mail | Livré | Livré le 13/11/2026 ; déploiement en production à confirmer (non listé parmi les mesures confirmées en ligne le 14/11/2026) | |
| M-06e | Appareils mobiles : jeton valable 90 jours au plus sans prolongation, expirés purgés, liste des appareils et révocation (un appareil ou tous) dans Mon compte, code TOTP exigé à l'émission | Livré | Livré le 13/11/2026 ; déploiement en production à confirmer (non listé parmi les mesures confirmées en ligne le 14/11/2026) | |
| M-06f | Jeton du lien d'enquête de satisfaction : expiration 90 jours après l'envoi, refus de la réponse côté serveur, message neutre | Partiel | Livré le 13/11/2026 ; déploiement en production à confirmer (non listé parmi les mesures confirmées en ligne le 14/11/2026) | Le jeton n'est pas haché : il reste dans la colonne surveys.token. À traiter avec un lot qui possède les fichiers d'envoi |
B.2. Droits des personnes et conservation
| Réf. | Mesure | Livraison | Statut de déploiement | Limites, décisions, échéance |
|---|---|---|---|---|
| M-07 | Export et effacement complets : registre unique de 44 sources de données personnelles (fichiers et tables), utilisé par l'export et l'effacement, avec test automatique qui échoue si une source n'est pas déclarée. L'export ne contient ni jeton ni secret, ni code de porte, ni pièce | Livré | Déployé en production le 14/11/2026 | Testé sur MariaDB 13.0.2 et sur fichiers, pas sur MySQL 8. Les sauvegardes déjà faites ne sont pas modifiées. En MySQL, le journal d'audit n'est nettoyé que dans sa colonne de détails : un nom écrit dans la colonne « action » ne serait pas retiré. Les données de santé en texte libre ne sont pas repérées par leur contenu |
| M-07b | Demande des droits en ligne par la personne concernée : page publique par hôtel (gdpr.php?hotel=…), confirmation par un lien à usage unique (2 h, jeton haché), traitement par l'Hôtel dans ses réglages ; lien « Exercer mes droits » au pied des pages publiques |
Livré | Déployé en production le 14/11/2026 | L'envoi réel de l'e-mail de confirmation n'a pas été testé (transport de capture) |
| M-08 | Purge automatique des durées de l'annexe A.4, y compris purge de secours des pièces d'identité orphelines, avec simulation préalable, suivi du dernier passage et alerte par e-mail au-delà de 48 h sans passage | Livré | Déployé et activé le 14/11/2026 | Le premier passage réel supprime d'un coup tout ce qui est déjà échu : il ne se fait qu'après une simulation relue. Pas de test de charge sur un gros hôtel. Le fichier includes/data/.retention-armed est posé depuis le 14/11/2026 : les durées de l'annexe A.4 sont appliquées chaque nuit, de 2 h à 6 h ; le premier passage réel n'a pas encore eu lieu à la date de cette mise à jour ; la simulation du 14/11/2026 sur les données réelles a compté 4 éléments (3 copies de pièces d'identité orphelines et 1 jeton expiré) |
| M-09 | Export de fin de contrat avant suppression d'un hôtel | Prévu | Rien dans le code | La suppression d'un hôtel efface encore les pièces comptables (audit M3, non traité). [À COMPLÉTER : échéance] |
| M-10 | Effacement répercuté dans les copies secondaires (fichiers de repli .bak et .corrupt-*) et rejeu des effacements après toute restauration de sauvegarde (registre des effacements, empreintes HMAC, 24 mois) ; corbeille d'un hôtel supprimé purgée à 30 jours |
Livré | Déployé en production le 14/11/2026 (effacement et rejeu des effacements) ; purge de la corbeille à 30 jours : purge activée le 14/11/2026 | Les sauvegardes déjà faites ne sont modifiées qu'à la fin de leur rotation. Les copies hors application (anciens instantanés) ne sont pas traitées |
| M-10b | Consentement marketing par canal (e-mail, SMS, WhatsApp) avec preuve (date, source, version du texte, auteur, empreinte HMAC de l'IP) et historique ; liste de suppression consultée par tous les envois (newsletter, scénarios, réactivation, API partenaire, enquêtes) ; désinscription effective dans les deux moteurs (jeton dérivé, page à POST, List-Unsubscribe) ; double opt-in pour l'inscription par formulaire ; consentement périmé après 3 ans sans interaction (réglable de 1 à 5 ans dans le code, aucun écran) ; un agent ne peut pas réinscrire une personne désinscrite |
Livré | Déployé en production le 14/11/2026 | Aucune source de rebond ou de plainte (retour SMTP) n'alimente la liste de suppression : la fonction est prête, pas branchée. Les clients dont le consentement est périmé ou sans preuve cessent de recevoir les campagnes depuis le déploiement du 14/11/2026 (comptage préalable : à confirmer). Les pages d'administration du lot n'ont pas toutes été ouvertes en HTTP connecté. Décision à prendre : frontière entre message de service et message commercial (L34-5 CPCE) |
| M-10c | Suivi d'ouverture et de clic désactivé par défaut (interrupteur de l'hôtel ET de la campagne) ; sans suivi, ni pixel ni lien de redirection ; avec suivi, mention dans le pied de message | Partiel | Déployé en production le 14/11/2026 | Même avec l'interrupteur, le pixel est présent pour tous les destinataires et les événements sont agrégés (sans lien avec la personne) : aucun écran ne recueille l'accord de suivi distinct. Décision à prendre : pixel sans consentement individuel ou réservé aux personnes ayant donné un accord |
| M-10d | SMS et WhatsApp : consentement distinct par canal, mention « Répondez STOP » ajoutée, STOP entrant traité, message « de service » limité à une liste (confirmation, accès, paiement, séjour) | Livré | Déployé en production le 14/11/2026 | Les fiches existantes n'ont que le consentement e-mail : plus aucun SMS marketing n'est envoyé tant que l'accord par canal n'est pas recueilli |
| M-10e | Boîte e-mail reçue (IMAP) : chiffrement « aucun » interdit, import des seuls expéditeurs rattachés à une fiche client ou à une réservation, quarantaine sans contenu pour les autres (30 jours), citations et signatures retirées, corps limité à 4 000 caractères | Livré | Livré le 13/11/2026 ; déploiement en production à confirmer (non listé parmi les mesures confirmées en ligne le 14/11/2026) | Une boîte réglée sur « aucun » cesse d'être relevée, avec message dans le journal |
| M-11 | Pièce d'identité facultative par défaut (réglage par hôtel : non, encouragée, exigée des seuls clients hors UE, EEE et Suisse, appliqué côté serveur) ; suppression de la copie dès validation par la réception (bouton, journalisé) ; durée par défaut 7 jours | Livré | Déployé en production le 14/11/2026 pour le chiffrement des nouveaux téléversements ; le bouton de suppression dès validation est à confirmer ; durée de 7 jours appliquée automatiquement par la purge activée le 14/11/2026 | Un hôtel qui a déjà enregistré son propre règlement garde son texte : à relire par lui. Base légale de la copie : décision à prendre. Le réglage est propre à chaque hôtel : la valeur des hôtels existants n'a pas été modifiée le 14/11/2026 (comportement de chaque hôtel à confirmer) |
| M-11b | Fiche de police séparée : champs structurés, collectée seulement si l'Hôtel active l'option et si la nationalité déclarée est hors UE, EEE et Suisse ; stockée chiffrée à part ; 183 jours après le départ | Décision à prendre | Déployé en production le 14/11/2026 | Désactivée par défaut. Durée, base légale et liste des pays à faire confirmer par l'avocat ; la Suisse est traitée comme l'UE |
| M-11c | Information au point de collecte (responsable, finalité, base légale, destinataires, durée lue dans le registre, droits, liens) sur le widget, les formulaires, le check-in, les enquêtes, les avis ; cases « J'accepte » obligatoires supprimées (la base est le contrat ou la demande de la personne), seule case de consentement : le marketing, séparée, facultative, non cochée | Livré | Livré le 13/11/2026 ; déploiement en production à confirmer (non listé parmi les mesures confirmées en ligne le 14/11/2026) | contact-handler.php et reservation-handler.php (points d'entrée hérités de l'ancien site mono-hôtel, que plus aucun formulaire n'appelle) sont fermés (réponse 410) et retirés de la liste d'accès du dossier includes/ |
B.3. Données sensibles et traçabilité
| Réf. | Mesure | Livraison | Statut de déploiement | Limites, décisions, échéance |
|---|---|---|---|---|
| M-12 | Droit distinct « identite » pour voir pièces, naissance, adresse, IP, signature, fiche de police et allergies (Super Admin et Admin ; pas Agent, Ménage, Comptable, Propriétaire) ; jamais accordé en session de support | Livré | Déployé en production le 14/11/2026 | Tout compte qui a l'onglet Paramètres a le droit d'office (décision à prendre) ; les comptes à liste d'onglets personnalisée sans Paramètres perdent l'accès jusqu'à ce qu'un administrateur coche le droit : à annoncer aux hôtels. Refus du droit en session de support : à confirmer |
| M-13 | Journal de chaque ouverture, téléchargement, suppression et réouverture d'une pièce, et de la lecture ou écriture des allergies (identifiant interne seulement, ni nom ni adresse) ; exports de masse (CSV, Excel, comptable) réservés à une permission export, confirmés par POST avec jeton CSRF, refusés en session de support, journalisés (qui, quoi, nombre de lignes) avec alerte au-delà de 500 lignes ; en-têtes no-store sur les pièces |
Livré | Déployé en production le 14/11/2026 | Les comptes à liste d'onglets personnalisée perdent l'export tant que la case n'est pas cochée. Certains noms de clients écrits par d'anciennes pages dans le journal d'audit ont été retirés pour les pages listées par le lot B ; le lot A en liste d'autres (admin/facturation.php, admin/planning.php, groups.php) à vérifier. Refus de l'export en session de support et envoi réel de l'alerte au-delà de 500 lignes : à confirmer |
| M-14 | Chiffrement AES-256-GCM des fichiers de pièce et de signature et des champs nom complet, naissance, adresse, IP de signature, fiche de police ; noms de fichiers aléatoires de 128 bits ; dossier fermé (Require all denied) ; contrôle du type réel, PDF actifs refusés |
Partiel | Déployé en production le 14/11/2026 pour les nouveaux téléversements de pièces d'identité et la fiche de police ; chiffrement des autres champs et des signatures : à confirmer ; anciennes pièces non chiffrées (migration non exécutée) | La clé est sur le même serveur que les données (includes/data/_platform/.checkin-key) tant que CHECKIN_KEY_FILE n'est pas défini hors de la racine web (à confirmer en production) : un attaquant qui lit le disque lit les deux. Il faut sauvegarder la clé avec les données (sans elle, tout est perdu). Le blocage du dossier par .htaccess ou nginx n'a pas été testé en HTTP réel. Les droits 0750 et 0600 n'ont été testés que sous Unix |
| M-15 | Secrets des réglages (clés de paiement, SMTP, API) chiffrés avec AES-256-GCM | Existant | En production avant le chantier (à confirmer) | La clé .encryption-key est stockée à côté des données. Les nouvelles sauvegardes la rangent dans un fichier séparé chiffré (M-24) ; sa séparation sur le serveur n'est pas faite |
| M-16 | Session de support : motif obligatoire, durée bornée par l'autorisation du Client, revérification à chaque requête, révocation immédiate, journal chez le Client | Existant | En production avant le chantier (à confirmer) | Livré le 13/11/2026 (déploiement en production à confirmer) : chaque page vue est journalisée chez l'hôtel ; le mode test de support est refusé sur un hôtel de production. Décision à prendre : interdire l'écriture en session de support sur un hôtel de production (non refusée aujourd'hui) |
| M-17 | « Retrouver mon check-in » : plus aucune redirection ni jeton affiché ; le lien est envoyé à l'adresse e-mail DE LA RÉSERVATION ; réponse identique que l'adresse existe ou non ; limites de débit par session, IP et e-mail ; étapes verrouillées après validation (réouverture par la réception) | Livré | Livré le 13/11/2026 ; déploiement en production à confirmer (non listé parmi les mesures confirmées en ligne le 14/11/2026) | Pas de second facteur : la mesure d'origine (second facteur) a été remplacée par l'envoi du lien à l'adresse de la réservation. L'envoi réel de l'e-mail n'a pas été testé |
B.4. Transmission et exploitation
| Réf. | Mesure | Livraison | Statut de déploiement | Limites, décisions, échéance |
|---|---|---|---|---|
| M-18 | Jetons de check-in, d'enquête et d'avis de 192 bits ; limitation des essais sur jetons inconnus | Existant | En production avant le chantier (à confirmer) | D'après l'audit, le jeton de check-in n'avait que 128 bits en mode MySQL. Livré le 13/11/2026 (déploiement en production à confirmer) : 192 bits partout, conservé sous forme d'empreinte SHA-256 (une fuite de la base seule ne donne pas de lien) avec une copie chiffrée pour renvoyer le lien. Le jeton d'enquête reste en clair (M-06f) |
| M-19 | Webhooks entrants SMS/WhatsApp signés, rejet si la signature manque ; webhooks sortants vers les partenaires signés (HMAC SHA-256) avec protection contre les requêtes vers des adresses internes | Existant | En production avant le chantier (à confirmer) | Livré le 13/11/2026 (déploiement en production à confirmer) : le webhook propre de l'hôtel exige HTTPS et porte une signature horodatée (X-Staylo-Signature) ; l'ancien en-tête X-Webhook-Signature, rejouable, est encore envoyé pour la transition (date de retrait : décision à prendre) |
| M-19b | Partenaires d'intégration : aucun webhook ni appel d'API sans autorisation de l'hôtel (écran « Partenaires connectés » : niveau de données, case de reconnaissance de l'accord de sous-traitance horodatée, révocation, journal 14 jours sans contenu) ; nom du voyageur seulement au niveau « avec identité » et avec le droit guests:read, jamais d'e-mail ni de téléphone dans un webhook ; secret de signature propre à l'hôtel |
Livré | Déployé en production le 14/11/2026 | Changement cassant : les partenaires actuellement rattachés ne répondent plus (403, plus de webhook) tant que l'hôtel ne les a pas autorisés ; le secret de signature propre à l'hôtel oblige les partenaires à adopter la nouvelle dérivation. Qualification juridique du partenaire : décision à prendre |
| M-19c | Export iCal : jeton de 256 bits conservé haché (un par chambre et un par hôtel), création, régénération et révocation dans Paramètres ; événements « Réservé » sans nom, blocages sans note ; refus neutre identique pour tous les cas ; limite de débit | Livré | Déployé en production le 14/11/2026 | Changement cassant : les abonnements iCal existants se sont arrêtés (404) au déploiement du 14/11/2026 ; les liens doivent être recréés et recollés chez les plateformes de réservation, sinon risque de double réservation. L'import iCal n'a pas été testé de bout en bout |
| M-20 | Pages d'administration, de check-in, formulaires, widget, pages légales et vitrines sans ressource externe (Tailwind compilé, Alpine à version figée, polices et icônes auto-hébergées) ; politique de sécurité de contenu stricte sur checkin/ et f/ |
Partiel | Déployé en production le 14/11/2026 (partiel : voir les limites) | Restent : les maquettes templates/*/index.html (chargent Google Fonts et jsDelivr ; refusées par .htaccess mais pas par nginx) et la page de lecture de la Salle d'audit (anti-robot Cloudflare Turnstile, quand il est actif). Tout nouveau fichier créé avec la balise du CDN fait échouer le test externe |
| M-21 | HTTPS forcé, HSTS un an (sans preload), nosniff, Referrer-Policy, Permissions-Policy, X-Frame-Options (retiré pour le widget) ; politique de sécurité de contenu de l'administration en mode « rapport seul » |
Partiel | Déployé en production le 14/11/2026 (partiel : politique de contenu en mode rapport seulement) | Apache et nginx n'ont jamais été essayés : les règles .htaccess et le modèle docs/nginx-staylo.conf ne sont testés qu'en lecture (le modèle nginx est destiné au VPS futur) ; php -S ignore .htaccess. Test HTTP réel obligatoire après chaque déploiement. La politique de contenu de l'administration n'est pas encore bloquante |
| M-21b | Fichiers techniques non servis : includes/.htaccess en liste blanche de 18 entrées appelées par adresse, blocage de error_log, *.log, .encryption-key, .checkin-key, *.bak, *.corrupt-*, fichiers cachés ; assets/ sans exécution de script ; .gitignore côté application et côté Infra |
Partiel | Déployé en production le 14/11/2026 (partiel : voir les limites) | Même limite que M-21 (jamais testé en HTTP réel sur Apache ni nginx). Une adresse oubliée dans la liste blanche donne un 403. Les dossiers tools/, tests/, migration/ et docs/ ne sont volontairement pas en ligne |
| M-22 | Clés des tâches planifiées transmises par l'en-tête X-Cron-Key (ou en ligne de commande) ; ?token= refusé (400) même avec la bonne clé ; crons de l'hôtel vérifiant qu'il existe et qu'il est actif |
Livré | Déployé en production le 14/11/2026 | Les tâches externes (n8n, hôtes, agent) qui appellent encore ?token= échouent : à migrer. Les clés déjà passées dans des adresses sont à renouveler |
| M-23 | Sauvegardes quotidiennes, conservées 30 jours | Existant | En production avant le chantier (à confirmer : la rotation réelle est à vérifier avant publication) | |
| M-24 | Sauvegardes chiffrées (zip AES-256), clés d'application dans un fichier séparé chiffré avec un autre mot de passe, SFTP ou FTPES seulement, rotation 30 jours (7 archives au moins conservées), copie hors site, alerte en cas d'échec, test de restauration | Partiel | Non fait : scripts de sauvegarde chiffrée hors serveur (SFTP ou FTPES) non configurés à ce jour (action d'Allan) ; le script est réécrit sur le poste de l'Éditeur, mais il ne sert qu'une fois le fichier local d'identifiants créé | Les transferts SFTP et FTPES n'ont jamais été exécutés (testés sur un dossier fictif) ; la clé d'hôte SSH doit être enregistrée ; le mot de passe FTP actuel est à considérer comme exposé et à changer ; les anciens zips non chiffrés et les dossiers _tmp-* sont à supprimer après un premier test de restauration réussi (actions d'Allan, document 12) |
| M-25 | Alertes : 10 échecs de connexion en 10 minutes, adresse de connexion jamais vue, nouveau compte de la plateforme, session de support, export massif, autorisation de support modifiée, MFA verrouillée ou réinitialisée, mode test refusé, purge en retard, chaîne d'audit rompue, violation non notifiée après 24 h ; canaux : Telegram, e-mail de la plateforme, bandeau rouge dans la plateforme | Livré | Livré le 13/11/2026 ; déploiement en production à confirmer (non listé parmi les mesures confirmées en ligne le 14/11/2026) | L'envoi réel Telegram et e-mail n'a pas été testé. Destinataires et seuil d'alerte d'export : décisions à prendre |
| M-26 | Procédure écrite de violation de données (document 09) et registre des violations dans l'application (data_breaches, écran Plateforme > Sécurité) |
Livré | Procédure : document prêt, à publier avec le dossier. Registre : déployé en production le 14/11/2026 | Vocabulaire du registre à aligner (« Hibook » y est affiché comme sous-traitant ou responsable) |
| M-26b | Journal d'audit chaîné (empreinte SHA-256 de la ligne précédente) dans les deux moteurs, vérification auditVerifyChain() |
Partiel | Déployé en production le 14/11/2026 | La suppression des dernières lignes n'est pas détectée ; un administrateur du serveur peut recalculer toute la chaîne ; pas d'ancrage externe de l'empreinte |
| M-27 | Aucune donnée de démonstration issue de données réelles | Livré | Livré le 13/11/2026 ; la démonstration en ligne n'est pas remplacée (inchangé) | Jeu 100 % fictif et script de contrôle prêts ; procédure de remplacement rédigée ; la démonstration en ligne contient encore des données à remplacer |
B.5. Intelligence artificielle (fonction facultative de l'offre Gestion et au-dessus, désactivée par défaut)
| Réf. | Mesure | Livraison | Statut de déploiement | Limites, décisions |
|---|---|---|---|---|
| M-28 | Fonction désactivée par défaut ; clé d'API fournie par l'Hôtel, sans clé la fonction refuse de s'exécuter ; plafonds d'appels et de jetons | Existant | En production avant le chantier (à confirmer) | |
| M-29 | Un seul message du voyageur est transmis, sans historique ; envoi automatique désactivé par défaut | Existant | En production avant le chantier (à confirmer) | |
| M-30 | Avant l'appel : masquage des e-mails, adresses web, IBAN, cartes bancaires (contrôle de Luhn), téléphones français et internationaux, références, pièces d'identité et suites opaques ; prénom et nom remplacés par un repère remis localement dans le brouillon ; message sensible (santé, handicap, grossesse, allergie, convictions religieuses, orientation) jamais envoyé, brouillon vide à traiter par un humain ; reconnaissance obligatoire « J'ai informé mes voyageurs » (horodatée) pour activer ; mention « Réponse rédigée avec l'aide d'une intelligence artificielle » en cas d'envoi automatique ; journal d'appel sans texte | Livré | Déployé en production le 14/11/2026 | Un agent déjà actif reste muet tant que l'hôtel n'a pas coché la reconnaissance. Aucun masquage ne garantit l'absence d'un nom de tiers écrit dans le message ni d'un numéro écrit en toutes lettres (dit à l'hôtel dans l'écran). La liste des mots sensibles est large (faux positifs : « gluten », « lactose »). Aucun appel réel au fournisseur n'a été fait. Base légale et transfert hors UE : décision à prendre |
Avant le déploiement du 14/11/2026, le texte du message du voyageur était transmis tel quel au fournisseur d'IA en production, y compris si le voyageur y avait écrit un numéro de téléphone ou une information de santé, et le texte d'information affiché à l'Hôtel dans l'administration était inexact. Depuis le 14/11/2026, le masquage des données personnelles et le blocage des mots de santé sont en ligne (M-30) ; aucun appel réel au fournisseur n'a été fait pour les tester.
Annexe C : sous-traitants ultérieurs
Mise à jour : 14/11/2026 [À COMPLÉTER : date de mise à jour au jour de la signature]. Version publiée : voir le document « Liste des sous-traitants ultérieurs ». Cette annexe reprend la liste de l'application (gdprSubprocessors(), 15 lignes, état affiché à l'Hôtel dans Paramètres > Sous-traitants, déployé en production le 14/11/2026), complétée de deux lignes propres à ce document : ADRD Consulting et Stripe pour les abonnements d'Hibook. Ces fournisseurs sont ceux de l'Éditeur Hibook ; ADRD Consulting est listé comme prestataire de développement et d'exploitation.
« Localisation » et « base de transfert » restent à confirmer tant que le contrat du fournisseur n'a pas été relu : aucune affirmation n'est faite ici sur un pays, une certification ou un mécanisme.
| Fournisseur | Service | Données concernées | Déclenchement | Choisi par | Localisation | Base de transfert |
|---|---|---|---|---|---|---|
| ADRD Consulting | Développement, maintenance et exploitation technique du service Staylo pour le compte d'Hibook : accès à l'administration, aux sauvegardes et au support, dans le cadre de sessions de support tracées | Toutes les données de l'Hôtel, dans la mesure où la mission l'exige (accès limité) | Permanent (sur mission) | L'Éditeur (Hibook) ; accord interne : document « 13-DPA-hibook-adrd » [À COMPLÉTER : date de signature] | [À COMPLÉTER : localisation des équipes et des postes ; à confirmer] | [À COMPLÉTER : aucun transfert hors UE à confirmer] |
| Hostinger | Hébergement du service, des fichiers et des sauvegardes de production [À COMPLÉTER : mutualisé ou VPS, centre de données] | Toutes les données de l'Hôtel et de ses voyageurs | Permanent | Staylo | [À COMPLÉTER : à confirmer] | [À COMPLÉTER : à confirmer] |
| Fournisseur d'envoi d'e-mails de la plateforme | Envoi des e-mails du service Staylo (invitations, alertes de compte) | Adresse, nom et contenu des e-mails de la plateforme | À chaque e-mail de la plateforme | Staylo | [À COMPLÉTER : nom du fournisseur SMTP de la plateforme et localisation] | [À COMPLÉTER] |
| Serveur d'e-mails de l'Hôtel | Envoi des e-mails de l'Hôtel à ses voyageurs (confirmations, factures, relances) | Adresse, nom, contenu des e-mails | À chaque e-mail envoyé | L'Hôtel (Paramètres > Messagerie). Sans réglage, le serveur d'e-mails de la plateforme est utilisé | Choisi par l'Hôtel | Voir le contrat de l'Hôtel |
| Stripe | Paiement par carte, caution, relances de paiement | Montant, libellé du produit (« Séjour |
Action du voyageur ou de l'Hôtel | L'Hôtel (sa propre clé Stripe) | [À COMPLÉTER : à confirmer] | [À COMPLÉTER : CCT ou DPF, à confirmer] |
| GoCardless | Prélèvement SEPA (caution, acomptes) | Numéro de réservation, identifiant de l'hôtel, montant ; plus aucun pré-remplissage : le voyageur saisit lui-même son nom, son adresse et son IBAN sur la page de GoCardless ; le motif libre d'un remboursement n'est plus envoyé | Quand l'Hôtel envoie un lien de mandat | L'Hôtel (son propre jeton) | [À COMPLÉTER : à confirmer] | [À COMPLÉTER : à confirmer] |
| Twilio | Réponses par SMS | Numéro de téléphone du destinataire et texte complet du message | À l'envoi d'un SMS (message écrit ou brouillon validé) | L'Hôtel (son compte) | [À COMPLÉTER : à confirmer] | [À COMPLÉTER : CCT ou DPF, à confirmer] |
| Meta (WhatsApp Business, Cloud API) | Réponses par WhatsApp | Numéro de téléphone du destinataire et texte complet du message | À l'envoi d'un message | L'Hôtel (son compte) | [À COMPLÉTER : à confirmer] | [À COMPLÉTER : CCT ou DPF, à confirmer] |
| Channex | Synchronisation avec les plateformes de réservation (channel manager) | Entrant : nom, prénom, e-mail, téléphone des voyageurs venant des plateformes ; sortant : disponibilités et tarifs, sans donnée personnelle | À chaque synchronisation (bouton ou automatique) | L'Hôtel (sa propre clé) | [À COMPLÉTER : à confirmer] | [À COMPLÉTER : à confirmer] |
| Anthropic | Brouillon de réponse par intelligence artificielle : désactivé par défaut, clé de l'Hôtel obligatoire | Texte du dernier message du voyageur après masquage des e-mails, téléphones, IBAN, cartes et références ; prénom et nom remplacés par un repère ; dates, type de logement, nombre de voyageurs, statut ; informations de l'établissement. Les messages sensibles (santé, convictions) ne sont jamais envoyés | Action de scénario ou action manuelle de l'Hôtel | L'Hôtel (sa propre clé) | [À COMPLÉTER : à confirmer] | [À COMPLÉTER : CCT ou DPF, à confirmer ; base légale et durée de conservation chez le fournisseur à confirmer] |
| Partenaires connectés (CRM, gestionnaire de canaux, comptabilité, agences) | Intégrations par API et webhooks | Selon le niveau accordé : identifiants, dates, statuts, montants ; nom du voyageur seulement au niveau « avec identité » ; fiches clients et messages seulement avec les droits correspondants de la clé | Automatique, à chaque événement, seulement pour les partenaires autorisés par l'Hôtel | L'Hôtel (autorisation, niveau de données, révocation) | Selon le partenaire | Selon le contrat avec le partenaire |
| Webhook propre de l'Hôtel | Envoi des événements vers le système choisi par l'Hôtel | Événements de réservation, paiement, message (le nom du voyageur figure dans l'événement de création de réservation) | Automatique, à chaque événement | L'Hôtel (adresse HTTPS et secret) | Choisi par l'Hôtel | Voir le contrat de l'Hôtel |
| Cloudflare (Turnstile) | Anti-robot de la « Salle d'audit » (accès de développeurs externes), et service DNS ou CDN si le domaine y est rattaché | Pour Turnstile : jeton de défi, adresse IP du visiteur. Aucune donnée de voyageur | Visite de la page concernée | Staylo | [À COMPLÉTER : à confirmer] | [À COMPLÉTER : à confirmer] |
Services utilisés par Staylo pour ses propres besoins, sans donnée de voyageur : Hostinger (API d'achat de noms de domaine et de boîtes e-mail pour les sites des hôtels : domaine, titulaire, nom de boîte, DNS), Telegram (alertes de sécurité à l'équipe : adresse e-mail masquée, titre de mission, motif ; masquage automatique des e-mails, téléphones et adresses web avant l'envoi), Stripe (abonnement et achat de domaine facturés à l'Hôtel).
Autres destinataires possibles, non sous-traitants de Staylo : outils de mesure d'audience Google Analytics 4 et Meta Pixel, qui ne se chargent sur le site de l'Hôtel que si celui-ci saisit leurs identifiants ET que le visiteur accepte les cookies (l'Hôtel en est alors seul responsable). Pour les partenaires d'intégration, voir l'article 7.6.