Trame d’Altitude récits parisiens

Document de démonstration · paramètres réels à compléter

Politique de confidentialité

Cette politique décrit d’abord le comportement actuel de la maquette statique, puis les informations qui devront être précisées si un traitement de demandes, de commandes ou de paiements est ajouté. Elle doit être actualisée avant publication afin de refléter exactement les outils et prestataires réellement employés.

Fonctionnement actuel. Les quatre pages sont des fichiers HTML autonomes. Le formulaire de la page principale utilise la méthode GET et ouvre localement la page de remerciement. Aucun serveur Trame d’Altitude n’est connecté : les informations saisies ne sont ni reçues par l’éditeur, ni enregistrées dans une base, ni utilisées pour répondre.

1. Responsable du traitement

Le responsable qui exploitera le service doit être identifié par sa dénomination légale, sa forme juridique, son adresse professionnelle et une adresse de contact consacrée à la protection des données : [À COMPLÉTER].

Les coordonnées visibles dans cette maquette — 27, rue des Cévennes, 75015 Paris, +33 1 84 27 16 53 et bonjour@trame-altitude.fr — sont fictives et servent uniquement d’exemple visuel. Elles ne constituent pas les coordonnées vérifiées d’un responsable réel.

2. Données collectées

Dans l’état actuel des fichiers, aucune donnée personnelle n’est collectée par Trame d’Altitude. Le formulaire comporte des champs de nom, adresse électronique, service souhaité et message, mais leur validation entraîne seulement une navigation entre deux fichiers statiques. Selon le navigateur, les valeurs peuvent apparaître temporairement dans l’adresse de la page locale ; il convient donc de ne saisir aucune information réelle ou sensible dans cette démonstration.

Si le formulaire est connecté ultérieurement, les catégories strictement nécessaires devraient être limitées aux informations de contact, au service demandé, à la date souhaitée, à la taille du groupe, aux besoins d’adaptation communiqués volontairement et aux échanges indispensables au suivi. Les données de paiement ne devraient pas transiter directement par ces pages et devraient être prises en charge par un prestataire spécialisé.

3. Finalités et bases légales

Une version opérationnelle pourrait traiter les informations afin de répondre à une demande, vérifier la disponibilité d’un guide, préparer une prestation, livrer un contenu numérique, exécuter un contrat, assurer le suivi comptable et satisfaire des obligations légales. Pour chaque finalité réellement retenue, l’éditeur devra indiquer une base juridique appropriée — mesures précontractuelles, exécution d’un contrat, obligation légale, intérêt légitime évalué ou consentement lorsque celui-ci est nécessaire — ainsi que les conséquences d’un refus de fournir les données indispensables.

Les adresses obtenues pour une demande ne devront pas être ajoutées automatiquement à une liste de communication promotionnelle. Toute prospection éventuelle devra être décrite séparément et respecter les règles applicables.

4. Durées de conservation

Aucune conservation par l’éditeur n’a lieu dans la maquette. Avant la connexion d’un service, un calendrier devra fixer des durées proportionnées pour les demandes sans suite, les dossiers clients, les contenus contractuels, les factures, les preuves de consentement, les échanges de réclamation et les données nécessaires à l’exercice des droits. Les durées ou critères de détermination sont : [À COMPLÉTER].

À l’issue de la durée utile, les données devront être supprimées, anonymisées de manière effective ou archivées séparément lorsqu’une obligation légale le justifie.

5. Destinataires

Dans la version actuelle, aucun destinataire ne reçoit les champs du formulaire. Dans une future version, l’accès devrait être limité aux personnes chargées des demandes et, selon l’organisation choisie, à des prestataires indispensables tels que l’hébergeur, l’outil de messagerie, le prestataire de formulaire, le service de paiement ou le professionnel de comptabilité. Leur identité ou leur catégorie, leur rôle et les garanties contractuelles devront être documentés : [À COMPLÉTER].

6. Transferts hors de l’Union européenne

Aucun outil externe n’est intégré à cette maquette. Si un futur prestataire traite des données hors de l’Union européenne ou de l’Espace économique européen, l’éditeur devra identifier le pays, le mécanisme juridique applicable et les garanties complémentaires éventuelles. En l’absence de transfert, la politique finale devra le dire simplement après vérification de l’ensemble des sous-traitants.

7. Cookies et traceurs

Les fichiers fournis n’installent volontairement aucun cookie, outil de mesure d’audience, pixel publicitaire ou traceur tiers. Ils ne chargent ni script, ni police, ni bibliothèque depuis un domaine externe. Le simple lien informatif vers une source extérieure n’exécute aucun contenu tiers dans la page.

Si des fonctions de mesure, de vidéo, de carte, de paiement ou de personnalisation sont ajoutées, un inventaire devra être réalisé. L’information et le recueil de choix devront alors être adaptés aux traceurs effectivement utilisés, sans afficher un bandeau trompeur lorsqu’aucun consentement n’est nécessaire.

8. Sécurité

Avant de recevoir des demandes réelles, l’éditeur devra mettre en place des mesures adaptées au risque : connexion chiffrée, contrôle des accès, mots de passe robustes, mises à jour, sauvegardes maîtrisées, limitation des journaux, procédure d’incident et contrats avec les prestataires. Aucune page statique ne peut à elle seule garantir la sécurité d’un traitement qui n’a pas encore été conçu.

9. Droits des personnes

Lorsque des traitements réels commenceront, les personnes pourront, selon les conditions prévues par le règlement général sur la protection des données et le droit français, demander l’accès à leurs données, leur rectification, leur effacement, la limitation du traitement, s’opposer à certains usages et exercer leur droit à la portabilité lorsque celui-ci s’applique. Elles pourront également retirer un consentement sans remettre en cause la licéité du traitement antérieur.

L’adresse d’exercice des droits, les informations nécessaires pour vérifier l’identité de manière proportionnée et le délai de réponse devront être indiqués ici : [À COMPLÉTER]. Une demande ne doit pas exiger davantage d’informations que nécessaire.

10. Réclamation auprès de la CNIL

Si une personne estime, après avoir contacté le responsable, que ses droits ne sont pas respectés, elle peut adresser une réclamation à la Commission nationale de l’informatique et des libertés (CNIL) selon les modalités proposées par cette autorité. Les coordonnées et procédures actuelles devront être consultées directement auprès de la CNIL au moment de la démarche.

11. Contact et mise à jour

Contact relatif à la protection des données : [À COMPLÉTER]. La date de dernière mise à jour devra être modifiée à chaque évolution importante du traitement. Lorsque le fonctionnement change, la politique doit être revue avant la mise en production, et non après le début de la collecte.

← Retour à l'accueil