Sécurité et confiance

1. Résumé d'une page

Notre état actuel honnête, au 02/07/2026 : horsenose est un produit à un stade précoce géré par un opérateur solo. Nous ne sommes PAS certifiés SOC 2 ou ISO 27001 aujourd'hui et nous n'avons pas encore réalisé de test d'intrusion externe. Cette page décrit ce que nous faisons, ce que nous détenons, ce que nous n'avons pas encore et ce qui figure sur la feuille de route. Nous préférons vous dire clairement où nous en sommes plutôt que de l’exagérer.

• Qui nous sommes. horsenose est un logiciel permettant de gérer un centre équestre : planifier les cours, suivre les présences et le mode de paiement des cavaliers, gérer les cartes de séances et les bons cadeaux, calculer les revenus des moniteurs et donner aux clients d'une écurie une vue de leurs propres réservations. Il est exploité par DF Daniel Fojcik, une entreprise individuelle polonaise (NIP 6472592229 / REGON 387798601, Marklowice), opérant sous le nom de Nose / horsenose.
• Nos deux rôles. Nous sommes le contrôleur de données pour nos propres données de compte, d'analyse et de sécurité, et un processeur de données agissant selon les instructions de chaque écurie pour les données du cavalier/client saisies par l'écurie. La relation avec le processeur est régie par notre accord de traitement des données (DPA). Voir « Cadrage de conformité » ci-dessous.
• Ce que nous détenons. Adresse e-mail du compte et nom/téléphone du profil facultatif ; adresses e-mail d'invitation ; les enregistrements opérationnels qu'une écurie saisit concernant ses cavaliers (noms, contacts, participation aux cours, cartes de séances/bons, étiquettes de suivi des paiements, notes en texte libre) ; codes PIN de planification hachés par bcrypt ; Jetons d'invitation hachés SHA-256. Nous ne détenons aucune donnée de carte de paiement ou bancaire et aucune donnée de santé. Inventaire complet dans « Données que nous détenons » ci-dessous.
• Ce qui le protège. TLS partout avec précharge HSTS ; cryptage au repos (AES-256) ; sécurité au niveau des lignes appliquée par la base de données isolant chaque centre équestre ; validation de session côté serveur ; réauthentification renforcée pour les actions destructrices et administratives ; une politique stricte de sécurité du contenu ; limitation du débit et protection contre les robots ; et un journal d'audit en annexe uniquement. Liste complète dans « Mesures techniques » ci-dessous.
• Où il s'exécute. UE par défaut : la base de données, la messagerie électronique, les analyses, la surveillance des erreurs et le magasin de limites de débit sont hébergés dans l'EEE. Il n'est pas 100 % EEE : deux bords (le réseau mondial de Cloudflare et la connexion facultative à Google aux États-Unis) se trouvent à l'extérieur, couverts par l'accord UE-États-Unis. Cadre de confidentialité des données et/ou clauses contractuelles types. Voir « Infrastructure : qui gère quoi et où » ci-dessous.
• Ce que nous n'avons pas encore. Pas de SOC 2, ISO 27001, de test d'intrusion externe ou de programme de bug bounty. Voir « Ce que nous n'avons pas encore – feuille de route » ci-dessous. Si votre processus d’approvisionnement nécessite aujourd’hui SOC 2, nous ne sommes pas encore la bonne personne.
• Comment nous contacter à propos de la sécurité. Envoyez un e-mail à support@horsenose.eu avec « Sécurité » dans la ligne d'objet. Voir « Réponse aux incidents (notification de violation dans les 72 heures) » et « Divulgation responsable ».

2. Données que nous détenons

Nous collectons le minimum nécessaire au fonctionnement du Service. Les catégories ci-dessous sont les données personnelles qui touchent au horsenose.

Ce que nous ne tenons pas

• Aucune carte de paiement ou données bancaires. Nous ne traitons pas les paiements des cavaliers. "Cash", "carte de séances", "bon cadeau" et "BLIK" sont des étiquettes de suivi d'enregistrements stables - et non des transactions à grande vitesse. La facturation de l'abonnement (les frais qu'une écurie paie pour le horsenose) est en direct, mais les données de carte sont entièrement traitées sur la caisse hébergée du fournisseur de paiement — Stripe pour les écuries polonaises, Dodo Payments (Merchant of Record) pour les écuries non polonaises — et ne nous parviennent jamais, nous restons donc hors de portée de la norme PCI DSS (voir « Cadrage de conformité » ci-dessous).
• Aucun document d'identité ni adresse. Nous ne collectons pas les adresses personnelles, les numéros de documents d'identité ou les identifiants gouvernementaux.
• Aucune donnée de catégorie spéciale (santé). Nous n'avons pas l'intention de collecter des données au titre de l'article 9 du RGPD et le produit n'est pas conçu pour les stocker. Il est demandé aux écuries (dans le DPA) de ne pas saisir de données de catégorie spéciale dans les champs de texte libre. Les notes concernant un cheval concernent un animal, pas une personne, et ne relèvent pas du RGPD.
• Aucun profil publicitaire, identifiant de reciblage ou suivi inter-sites. Aucun pixel Meta/LinkedIn/X/TikTok ; pas d'empreinte digitale du navigateur.
• Aucune donnée vendue, louée ou prêtée à des tiers.
• Aucune formation de modèles IA/ML sur vos données. Nous n'entraînons, n'affinons ni n'évaluons aucun modèle d'IA ou d'apprentissage automatique sur les données personnelles tirées de Horsenose. L'extension « pgvector » est activée dans notre Postgres pour les futurs cas d'utilisation de recherche interne, mais n'est, aujourd'hui, pas remplie d'embeddings dérivés de données personnelles.

3. Infrastructure : qui gère quoi et où

horsenose est une application Next.js hébergée sur Vercel, soutenue par une base de données Supabase Postgres, avec un petit ensemble de fournisseurs spécialisés (« sous-processeurs ») gérant chacun une tranche étroite. Aucun n’a accès à tout de bout en bout. Notre valeur par défaut est l'UE, et nous le disons honnêtement : la base de données, le courrier électronique, les analyses de produits et la surveillance des erreurs fonctionnent tous dans l'EEE. Il ne s'agit pas à 100 % de l'EEE : quelques bords se trouvent à l'extérieur, couverts par l'accord UE-États-Unis. Cadre de confidentialité des données et/ou clauses contractuelles types (CCS). Nous ne publierons pas une affirmation sans réserve selon laquelle « toutes les données restent dans l’UE » tant que cela est vrai.

La version canonique et toujours à jour de ce tableau — avec les catégories de données personnelles et les mécanismes de transfert par fournisseur — est conservée sur la page Sous-traitants ultérieurs ; la politique de confidentialité et le DPA renvoient à la même source plutôt que de conserver des copies divergentes.

4. Mesures techniques

Ce sont les contrôles réellement en place aujourd'hui. (Les contrôles que nous n'avons pas encore construits sont répertoriés séparément dans « Ce que nous n'avons pas encore – feuille de route » ci-dessous — nous ne présentons pas les mesures prévues comme étant actuelles.) C'est également la substance derrière le DPA → « Confidentialité, sécurité et sous-traitants », qui renvoie ici pour nos mesures techniques et organisationnelles.

Réseau et transports

• TLS pour tout le trafic, appliqué par Vercel et Supabase. HSTS est défini avec `max-age=63072000 ; includeSubDomains ; précharger`.
• Pas de contenu mixte — la politique de sécurité du contenu rejette les ressources « http:// ».

Isolement et autorisation des locataires

• La sécurité au niveau des lignes (RLS) s'étend à chaque centre équestre sur chaque table opérationnelle, appliquée dans la base de données elle-même — les données d'un centre équestre ne peuvent pas être lues par une autre même si le code de l'application présente un bogue. Il s’agit de la principale défense entre locataires.
• Portes de rôle au niveau de la couche d'application (authentifiées / de portée centre équestre / moniteur ou administrateur / super-administrateur) en tant que défense en profondeur au-dessus de RLS, jamais comme seule ligne.
• Les vérifications de couche d'itinéraire nécessitent une session active pour les chemins protégés et un statut de super-administrateur pour la surface d'administration.

Authentification

• Connexion sans mot de passe — lien magique par e-mail (géré par Supabase Auth) ou connexion facultative à Google (OAuth). Aucun mot de passe n'est stocké.
• Validation de session côté serveur pour chaque demande protégée : le cookie de connexion seul n'est jamais fiable.
• Réauthentification renforcée pour les actions destructrices et administratives : un cookie intensif de courte durée, signé séparément, est requis pour les opérations telles que la suppression de compte, les changements de rôle du dernier administrateur, la désactivation groupée, l'archivage centre équestre et toutes les écritures du super-administrateur ; le step-up manquant ou expiré échoue fermé.
• La surface platform-admin renvoie 404 lorsqu’aucun super-administrateur n’est configuré, son existence n’est donc pas divulguée.

Gestion des secrets et des informations d'identification

• Les PIN de planification sont stockés sous forme de hachages bcrypt ; Les jetons d'invitation sont stockés sous forme de hachages SHA-256 : à usage unique, limité dans le temps (expiration de 7 jours) et lié au courrier électronique ; les jetons bruts ne sont jamais conservés.
• La clé de rôle de service de base de données est réservée au serveur : elle n'est jamais intégrée au JavaScript client ; un validateur au moment de la construction échoue la construction si une variable sensible est mal préfixée.

Gestion des entrées et des sorties

• Validation de schéma à chaque limite d'entrée du serveur — la validation côté client est traitée comme UX uniquement ; le serveur est la limite de confiance.
• Une politique de sécurité de contenu stricte avec un occasion occasionnel par demande, plus un ensemble d'en-têtes de sécurité verrouillés (`X-Content-Type-Options`, `X-Frame-Options` / `frame-ancestors`, `Referrer-Policy`, en-têtes d'isolation d'origine croisée et une `Permissions-Policy` restrictive).
• Sortie automatique s'échappant ; Le contenu créé par l'utilisateur est du texte brut à ce stade.

Protection contre les abus et les robots

• Limitation du débit sur la connexion, l'inscription, le lien magique, l'acceptation d'invitation, l'exportation/effacement et d'autres points de terminaison sensibles (par e-mail, par IP, par utilisateur ou par centre équestre en fonction de l'action ; chaque stratégie est ouverte ou fermée en cas d'échec par conception).
• Protection contre les robots Cloudflare Turnstile sur le formulaire de connexion, le formulaire d'inscription, la demande de lien magique, la page d'acceptation d'invitation et la saisie du code PIN de planification publique.

Données au repos et piste d'audit

• Chiffrement au repos via Supabase (AES-256).
• Un journal d'audit en annexe uniquement enregistre les événements liés à la sécurité (authentification, changements de rôle et d'adhésion, événements financiers, exportations, suppressions). Elle est toujours écrite et se distingue de la télémétrie opérationnelle.
• Surveillance des erreurs avec nettoyage des données personnelles : avant qu'une erreur ne soit envoyée à Sentry, un nettoyeur personnalisé supprime les adresses e-mail, les numéros de téléphone, les corps des messages, les notes et tout champ qui ressemble à un jeton. Ce qui reste est le contexte technique plus un UUID d'utilisateur pseudonyme, l'identifiant centre équestre, les paramètres régionaux et le nom de l'opération défaillante.

Sauvegardes et récupération

• Supabase fournit des sauvegardes quotidiennes automatisées (conservation de 7 jours au niveau actuel ; une rétention plus longue est prévue à mesure que le service évolue). Vercel conserve les déploiements antérieurs pour une restauration quasi instantanée d'une mauvaise version.

5. Mesures organisationnelles

• Opérateur solo. horsenose est dirigé par une seule personne (Daniel Fojcik). Aucun employé n’a accès à la production pour le moment. Si cela change – par exemple, un entrepreneur ayant accès à la production est intégré – cette page sera mise à jour et les écuries actives seront informées.
• Les données de production restent sur l'infrastructure gérée. Les sauvegardes de la base de données de production ne sont pas stockées sur les machines locales ; le développement local utilise une base de données distincte avec des données synthétiques.
• Moins de privilèges pour les comptes de service. La clé de rôle de service de base de données est limitée à une utilisation côté serveur uniquement ; L'accès à la base de données du navigateur utilise une clé limitée derrière la sécurité au niveau des lignes.
• Gestion des secrets. Les secrets résident dans la configuration de l'environnement du fournisseur d'hébergement et dans un fichier local gitignoré — jamais validé dans le référentiel. Les secrets de production ne sont pas copiés sur les machines locales.
• Journalisation des accès côté fournisseur. Les actions administratives sur nos fournisseurs sont enregistrées par ces fournisseurs ; nous les examinons de manière ponctuelle.
• Confidentialité. Le personnel (actuellement le propriétaire) est tenu à la confidentialité concernant les données personnelles traitées via le Service, comme indiqué dans le DPA.
• Changez de discipline. Les modifications de code passent par un test strict de type, de lint et de test automatisé avant le déploiement, et les migrations de bases de données sont appliquées à un environnement intermédiaire avant la production.

6. Réponse aux incidents (notification de violation dans les 72 heures)

Surveillance. Les erreurs sont transmises à Sentry (avec le nettoyage des données personnelles décrit dans « Mesures techniques » ci-dessus) ; les diagnostics au niveau de la demande sont disponibles dans les journaux d'hébergement ; un moniteur de disponibilité et des alertes de taux d’erreur font partie de la ligne de base de renforcement. Le journal d'audit en annexe uniquement fournit un enregistrement durable des événements liés à la sécurité aux fins d'enquête.

Notre engagement en matière de notification des violations. Si une violation de données personnelles se produit et est susceptible d'entraîner un risque pour les droits et libertés des personnes concernées, nous :

• Avertir l'autorité de contrôle compétente — le président d'UODO en Pologne — sans retard injustifié et, si possible, dans les 72 heures après avoir pris connaissance de la violation (Article 33 du RGPD).
• *Lorsque la violation est susceptible d'entraîner un risque élevé* pour les personnes concernées, informez-les sans délai injustifié, en décrivant la nature de la violation, les catégories de données impliquées, les conséquences probables et les mesures prises (Article 34 du RGPD**).
• Lorsque nous agissons en tant que sous-traitant pour une écurie, informez cette écurie (le responsable du traitement) sans retard injustifié afin qu'elle puisse remplir ses propres obligations en vertu de l'article 33/34 envers ses cavaliers.

Cela reflète la politique de confidentialité et le DPA. Il indique comment nous avons l'intention de mettre en œuvre une obligation déjà imposée par le RGPD. Il ne s'agit pas d'une promesse contractuelle supplémentaire au-delà du RGPD. Un runbook de réponse aux incidents formellement documenté figure sur la feuille de route (voir « Ce que nous n'avons pas encore – feuille de route » ci-dessus) ; d'ici là, une équipe composée d'une seule personne répond de manière ponctuelle dans les délais ci-dessus.

Contact. Non urgent : support@horsenose.eu. Sécurité (urgent) : envoyez un e-mail à support@horsenose.eu avec « Sécurité » dans la ligne d'objet.

7. Ce que nous n’avons pas encore – feuille de route

C’est cette rubrique qui fait la crédibilité du reste de la page : on ne cache pas la lacune. Nous sommes une petite entreprise en phase de démarrage, et plusieurs contrôles auxquels un acheteur plus important peut s'attendre ne sont pas encore en place.

Si le flux d'approvisionnement d'une écurie potentielle nécessite aujourd'hui SOC 2, nous ne sommes pas actuellement la bonne personne — et nous le dirons honnêtement plutôt que de bloquer la conversation.

8. Cadrage de conformité

RGPD (Règlement 2016/679). horsenose opère sous un double rôle : contrôleur pour les données dont il détermine les finalités et les moyens (visiteurs du site marketing, comptes/données de contact des administrateurs et moniteurs de l'écurie, analyses de produits soumises au consentement et données de sécurité/prévention des abus), et processeur pour les données opérationnelles du cavalier/client qu'un centre équestre entre — là, le centre équestre est le contrôleur et les processus horsenose sur les instructions documentées de l’écurie en vertu du DPA (article 28 RGPD). Les sous-traitants ultérieurs opèrent dans le cadre de contrats au titre de l'article 28 (DPA + SCC/DPF lorsqu'un transfert quitte l'EEE) — voir la page Sous-traitants ultérieurs.

Données des enfants. Les centres équestres enseignent régulièrement aux enfants, c'est pourquoi horsenose traite sciemment les données des mineurs pour le compte d'une écurie (par exemple, un enfant inscrit comme participant à un cours, souvent par un parent qui est client de l'écurie). L'écurie est responsable de la base légale et de toute autorisation ou autorité parentale requise (article 8 du RGPD) ; Horsenose minimise ce que l'on sait d'un enfant et ne cible ni ne commercialise directement les enfants. Voir Politique de confidentialité → « La vie privée des enfants ».

Les droits des personnes concernées sont pris en charge, y compris l'accès/la portabilité en libre-service via une exportation JSON sur /account/export et l'effacement via /account/delete (un délai de grâce réversible de 30 jours et une réauthentification progressive s'appliquent ; lors de l'effacement, nous supprimons les identifiants directs plutôt que de les supprimer définitivement — pseudonymisation en vertu de l'article 4, paragraphe 5 du RGPD, pas anonymisation complète en vertu du considérant 26 ; voir le tableau de conservation dans la Politique de confidentialité → « Combien de temps conservons-nous les données (conservation) » pour le détail au niveau du champ). Pour les données des cavaliers, le responsable du traitement est l'écurie, donc un cavalier exerce ses droits sur son écurie et son assistance en tant que sous-traitant.

PCI DSS — non applicable. Nous ne traitons, ne stockons ni ne transmettons les données de la carte ; espèces/carte de séances/bon cadeau/BLIK sont des étiquettes de suivi (voir « Données que nous détenons » ci-dessus). Pour la facturation des abonnements, le chemin des données de la carte est entièrement effectué par le fournisseur de paiement sur sa caisse hébergée — Stripe (processeur de paiement) pour les écuries polonaises, avec horsenose comme commerçant, et Dodo Payments comme Merchant of Record pour les écuries non polonaises — de sorte que horsenose ne reçoit jamais de données de carte et reste hors de portée PCI.

Loi européenne sur l'IA — non applicable. horsenose est un outil opérationnel pour les centres équestres ; il ne forme, ne développe ni ne déploie de modèles d'IA, et aucun composant n'utilise l'apprentissage automatique ou l'IA générative pour traiter les données personnelles. L'extension Postgres « pgvector » est activée pour d'éventuels futurs cas d'utilisation de recherche interne, mais n'est pas remplie aujourd'hui avec des intégrations dérivées de données personnelles ; si cela change, nous publierons une position sur la loi européenne sur l'IA et un engagement de « absence de formation sur les données personnelles » avant la livraison de la fonctionnalité.

ePrivacy / cookies. Les analyses facultatives (PostHog) se chargent uniquement sur consentement ; les cookies strictement nécessaires sont exemptés en vertu de l’article 5, paragraphe 3, de la directive ePrivacy. Voir la politique en matière de cookies.

9. Divulgation responsable

Si vous pensez avoir trouvé une faille de sécurité dans Horsenose :

• E-mail à [support@horsenose.eu](mailto:support@horsenose.eu) avec `Security` dans la ligne d'objet. (Une adresse `security@` dédiée et une clé PGP sont prévues — voir « Ce que nous n'avons pas encore – feuille de route » ci-dessus.)
• Incluez suffisamment de détails pour reproduire le problème.
• Accordez-nous un délai raisonnable pour enquêter et remédier à la situation avant toute divulgation publique.

Ce que vous pouvez attendre de nous :

• Une reconnaissance et une première évaluation dès que raisonnablement possible. horsenose est un service exploité en solo et ne peut garantir une réponse le jour même ; nous ne laisserons pas un rapport crédible sans surveillance.
• Le statut est mis à jour à des intervalles raisonnables pendant que le problème est trié ou résolu.
• Créditez toute divulgation post-fixe, si vous le souhaitez (facultatif).

Ce que nous ne pouvons pas encore offrir : nous ne payons pas de primes monétaires contre les bugs à ce stade. Nous le dirons clairement si et quand un programme de primes sera disponible.

Portée et sphère de sécurité. Les recherches de sécurité de bonne foi qui suivent cette politique, restent dans vos propres comptes, évitent de dégrader le Service pour d'autres et n'accèdent pas à des données autres que les vôtres ne seront pas traitées comme une violation de notre Politique d'utilisation acceptable ou de nos Conditions d'utilisation. N'essayez pas d'accéder aux données d'une autre écurie ou d'un autre cavalier, et n'exécutez pas de grattage automatisé ou de tests de déni de service sur le Service.

10. Journal des modifications