StationID
Politique de confidentialité
Document de préparation. Les choix indiqués comme à valider ne constituent pas des engagements ou conclusions juridiques validés.
Responsable du traitement et contact
L’identité de la personne physique ou morale qui détermine effectivement les finalités et moyens des traitements liés à StationID reste à confirmer. La SASU DevSys Studio est en cours d’immatriculation et n’est pas présentée ici comme une société déjà immatriculée.
Responsable : À identifier avant activation de la collecte
Contact pour les droits : À confirmer
Traitements repérés dans le code
Le formulaire Contact peut recueillir le nom, l’adresse e-mail, le téléphone et la commune (facultatifs), ainsi qu’un message. Sa fonction envisagée est de répondre aux demandes. Il est actuellement fermé par un gate de configuration. Tant que ce gate reste fermé, ces données ne doivent pas être soumises ni envoyées par ce formulaire.
Le code applicatif maintient un jeton CSRF et des champs de retour (nom, e-mail, téléphone, commune et erreurs de validation) dans une session temporaire ; le texte du message n’y est pas conservé. Il calcule une empreinte HMAC de l’adresse IP pour une limitation de débit de quinze minutes et l’enregistre dans var/contact-rate-limit.json. La suppression d’entrées expirées survient lors d’une soumission valide ultérieure : une durée effective de purge doit être contrôlée.
Le code d’envoi utilise Brevo pour transmettre une notification au destinataire configuré et un accusé transactionnel minimal à l’adresse saisie. Cela décrit le code, pas le DPA, la localisation, les transferts, la rétention du compte ni l’état de configuration de production : ces éléments sont à vérifier avant activation.
Finalités et bases légales — décisions à prendre
Réponse à une demande entrante et prévention des abus sont les finalités envisagées pour Contact. Le responsable doit déterminer et documenter la base légale appropriée pour chaque finalité et préciser le traitement de demandes précontractuelles et générales. Aucune base n’est publiée comme définitivement retenue dans ce projet.
Les journaux techniques peuvent être nécessaires à la sécurité, au fonctionnement et au diagnostic. Les fichiers de journal actifs, leur contenu, leurs accès et leur purge doivent être vérifiés sur le serveur avant d’arrêter finalités et bases.
Destinataires, sous-traitants et localisation
À vérifier sur les contrats et la configuration effectifs : hébergeur et entité OVH contractante, Brevo et services utilisés, personnes autorisées à accéder aux demandes, journaux, sauvegardes et sessions. La page officielle d’OVHcloud identifie OVH SAS et son siège au 2 rue Kellermann, 59100 Roubaix ; confirmer que c’est bien l’entité contractante du site. Obtenir et examiner le DPA Brevo applicable, les lieux de traitement, sous-traitants ultérieurs et éventuels transferts hors EEE avant activation.
Destinataires : À confirmer
Hébergement/pays : OVHcloud / À confirmer
Transferts hors EEE : À vérifier, aucune absence de transfert n’est affirmée
Durées et effacement
Aucune durée validée n’est actuellement communiquée pour les demandes dans les boîtes de réception, les accusés et traces Brevo, les journaux d’accès/erreurs, les sauvegardes, le fichier de limitation de débit ou les sessions PHP. La durée de session en mémoire applicative est configurée à 15 minutes, mais la purge PHP dépend de sa configuration effective. Définir et vérifier chaque durée et procédure d’effacement avant activation.
Durée des demandes : 12 mois après le dernier échange
Durée des journaux : À confirmer avec l’hébergeur
Journaux, cookies et traceurs
Les exemples Apache du dépôt utilisent des journaux d’accès « combined », susceptibles de contenir adresse IP, horodatage, ressource, statut, navigateur et référent. La configuration active et les journaux PHP doivent être vérifiés ; ce dépôt ne détermine ni leur durée ni qui y a accès. Aucun outil d’audience ou traceur publicitaire n’a été identifié dans le code applicatif audité ; vérifier aussi l’infrastructure de production.
Quand Contact est activé, le code utilise un cookie de session nommé stationid_contact avec HttpOnly, SameSite=Lax et Secure selon l’environnement HTTPS. Son expiration navigateur est à la fermeture de session ; les données temporaires de session sont soumises à la configuration PHP réelle. Le comportement des cookies en mode gate fermé et des mécanismes ajoutés par l’hébergeur reste à vérifier.
Droits et réclamation
Selon les conditions applicables, les personnes peuvent demander l’accès, la rectification, l’effacement, la limitation ou s’opposer à certains traitements ; la portabilité s’applique dans les cas prévus. Une demande pourra être adressée au responsable aux coordonnées ci-dessus une fois celles-ci confirmées. Une réclamation peut être adressée à la CNIL. Définir le processus de réception, vérification d’identité et réponse avant activation de Contact.
Projet préparé le 19 octobre 2026. Non validé pour une collecte commerciale.