Sécurité et confiance

1. Résumé d'une page

Notre état actuel honnête, au 8 juillet 2026 : Nose 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 et ce que nous n'avons pas encore. Nous préférons vous dire clairement où nous en sommes plutôt que de l’exagérer.

• Qui nous sommes. Nose 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 for Horse (« Nose »).
• Nos deux rôles. Nous sommes le responsable du traitement pour nos propres données de compte, d'analyse et de sécurité, et un sous-traitant agissant selon les instructions de chaque écurie pour les données du cavalier/client saisies par l'écurie. La relation de sous-traitance 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 ; chiffrement au repos (AES-256) ; sécurité au niveau des lignes appliquée par la base de données isolant chaque écurie ; 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 ajout seul (append-only). Liste complète dans « Mesures techniques » ci-dessous.
• Où il s'exécute. Sur plus d'une région de données, et nous en ajoutons à mesure de notre croissance. Les données clients des écuries de la région États-Unis sont stockées aux États-Unis. Le Service est exploité, administré et pris en charge depuis l'Union européenne. Les écuries de notre région UE sont desservies depuis l'EEE. Quelques services sont communs aux deux régions et fonctionnent dans l'EEE — l'e-mail transactionnel, la surveillance des erreurs, les analyses soumises au consentement — et quelques composants fonctionnent à l'échelle mondiale. Les régions et les mécanismes de transfert de chaque fournisseur, pour chaque région de données, figurent sous « Infrastructure : qui gère quoi et où » ci-dessous et sur la page Sous-traitants ultérieurs.
• Ce que nous n'avons pas encore. Pas de SOC 2, ISO 27001, de test d'intrusion externe ou de programme de bug bounty. Si votre processus d’approvisionnement nécessite aujourd’hui SOC 2, nous ne sommes pas encore le bon choix.
• Comment nous contacter à propos de la sécurité. Envoyez un e-mail à support@nose.horse avec `Security` dans la ligne d'objet. Voir « Réponse aux incidents (notification de violation dans les 72 heures) » et « Divulgation responsable » ci-dessous.

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 à Nose.

Lorsqu'une ligne indique la région de votre écurie, il s'agit de la région UE ou de la région États-Unis — fixée au moment de la création de l'écurie et détaillée sous « Infrastructure : qui gère quoi et où » ci-dessous.

Ce que nous ne détenons pas

• Aucune donnée de carte de paiement ou bancaire. Nose n'est jamais partie à un paiement et ne traite jamais de données de carte. Les méthodes hors ligne (« espèces », « carte de séances », « bon », « virement ») sont des étiquettes de suivi qu'une écurie enregistre — pas des transactions que Nose exécute. Pour la facturation de l'abonnement de l'écurie (Stripe pour les écuries polonaises, Dodo Payments en tant que marchand de référence (Merchant of Record) pour les écuries non polonaises) et pour les paiements en ligne des cavaliers lorsqu'une écurie les active (Stripe, avec règlement sur le propre compte de l'écurie), les données de carte sont traitées entièrement sur la caisse propre du fournisseur de paiement et ne nous parviennent jamais — nous restons donc hors du champ d'application 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 Nose. 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ù

Nose 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-traitants ultérieurs ») gérant chacun une tranche étroite. Aucun n’a accès à tout de bout en bout. Nose fonctionne dans deux régions de données : une région UE et une région États-Unis. Les données clients des écuries de la région États-Unis sont stockées aux États-Unis. Le Service est exploité, administré et pris en charge depuis l'Union européenne. Les données opérationnelles d'une écurie ne se trouvent que dans la base de données de sa propre région — il n'y a pas de réplication entre les régions, ni aucun chemin dans l'application qui lise les données d'une région depuis l'autre. Trois services sont communs aux deux régions et restent dans l'EEE — l'e-mail transactionnel, la surveillance des erreurs et les analyses de produits soumises au consentement. Le tableau ci-dessous indique la région de chaque fournisseur pour chaque région de données ; la liste canonique, avec les catégories de données et les mécanismes de transfert, est la page Sous-traitants ultérieurs.

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 ; 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. 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; preload`.
• 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) cloisonnée par écurie sur chaque table opérationnelle, appliquée dans la base de données elle-même — les données d'une écurie 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.
• Contrôles de rôle au niveau de la couche d'application (authentifié / de portée écurie / moniteur ou administrateur / super-administrateur) en tant que défense en profondeur au-dessus de RLS, jamais comme seule ligne.
• Les vérifications au niveau des routes 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 de réauthentification (step-up) 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 d'une écurie et toutes les écritures du super-administrateur ; un step-up manquant ou expiré entraîne un refus (fail-closed).
• 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és dans le temps (expiration de 7 jours) et liés à une adresse e-mail ; 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 exécuté au moment du build fait échouer celui-ci 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 nonce unique 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).
• Échappement automatique des sorties ; 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 écurie en fonction de l'action ; chaque politique est fail-open ou fail-closed 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 du planning public.

Données au repos et piste d'audit

• Chiffrement au repos via Supabase (AES-256).
• Un journal d'audit en ajout seul (append-only) enregistre les événements liés à la sécurité (authentification, changements de rôle et d'adhésion, événements financiers, exportations, suppressions). Il est toujours écrit 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 de l'écurie, 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. Nose 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.
• Moindre privilège 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.
• Rigueur des changements. Les modifications de code passent par un contrôle strict de typage, de lint et de tests automatisés avant le déploiement, et les migrations de bases de données sont appliquées à un environnement de préproduction 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 ajout seul 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 nous engageons à :

• 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, les informer 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, informer cette écurie (le responsable du traitement) sans retard injustifié afin qu'elle puisse remplir ses propres obligations au titre des articles 33 et 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 ; 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@nose.horse. Sécurité (urgent) : envoyez un e-mail à support@nose.horse avec `Security` dans la ligne d'objet.

7. Cadrage de conformité

RGPD (Règlement 2016/679). Nose opère sous un double rôle : responsable du traitement 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 sous-traitant pour les données opérationnelles du cavalier/client qu'une écurie saisit — là, l'écurie est le responsable du traitement et Nose traite selon 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, l'avenant britannique, ou un mécanisme équivalent lorsqu'un transfert franchit des régions) — voir la page Sous-traitants.

Données des enfants. Les centres équestres enseignent régulièrement aux enfants, c'est pourquoi Nose 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 tout consentement ou autorité parentale requis en vertu du droit qui lui est applicable (article 8 du RGPD dans l'UE et au Royaume-Uni ; COPPA et droit des États aux États-Unis) ; Nose réduit au minimum ce qui est détenu au sujet d'un enfant, ne cible pas les enfants et ne leur adresse aucune communication commerciale directe. 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 renforcée 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 auprès de son écurie et Nose l'assiste en tant que sous-traitant.

PCI DSS — non applicable à Nose. Nous ne traitons, ne stockons ni ne transmettons de données de carte. Pour la facturation de l'abonnement de l'écurie, le chemin des données de carte est entièrement pris en charge par le fournisseur de paiement sur sa caisse hébergée — Stripe (prestataire de services de paiement) pour les écuries polonaises, avec Nose comme commerçant, et Dodo Payments comme marchand de référence pour les écuries non polonaises. Pour les paiements en ligne des cavaliers, lorsqu'une écurie les active, les données de carte, de portefeuille ou (en Pologne) de BLIK sont entièrement prises en charge par Stripe (via Stripe Connect) et se règlent sur le propre compte Stripe de l'écurie — l'écurie est le commerçant et Stripe est le prestataire de services de paiement conforme PCI, tandis que Nose ne fait que relayer les instructions et ne reçoit jamais de données de carte. Dans tous les cas, Nose ne reçoit jamais de données de carte et reste hors du champ d'application PCI.

Loi européenne sur l'IA — non applicable. Nose 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 d'embeddings dérivés 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.

8. Divulgation responsable

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

• E-mail à [support@nose.horse](mailto:support@nose.horse) avec `Security` dans la ligne d'objet. (Une adresse `security@` dédiée et une clé PGP sont prévues.)
• 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. Nose 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.
• Une mention de votre nom dans toute divulgation après correction, 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 d'extraction automatisée (scraping) ni de tests de déni de service contre le Service.

9. Journal des modifications