Sécurité

• L'application tourne sur Vercel, en région européenne (Paris).
• Les données sont stockées dans PostgreSQL sur Supabase, en formule Pro, dans une région européenne.
• La base n'est atteinte que depuis notre propre code serveur, via Prisma. L'API de données publique de Supabase est fermée.

• Tout est servi en HTTPS. Strict Transport Security est réglé sur deux ans et couvre les sous-domaines, de sorte qu'un navigateur ne retombe pas en HTTP non chiffré. L'en-tête porte aussi la directive de préchargement, mais le domaine n'a pas été soumis à la liste de sites définitivement sécurisés intégrée aux navigateurs, nous ne revendiquons donc pas cette inscription.
• Le trafic entre l'application et la base de données passe par TLS.
• Le stockage de la base est chiffré au repos par Supabase.
• Nos propres sauvegardes externes de la base sont chiffrées en AES-256, la clé étant dérivée par PBKDF2, et écrites de façon à n'être lisibles que par leur propriétaire.

• Une Content Security Policy est appliquée sur chaque réponse et n'autorise que nos prestataires d'authentification, de paiement et de vidéo de formation. Elle est appliquée depuis le 28 juillet 2026, après trois semaines en mode signalement sans aucune violation.
• Les violations continuent d'être signalées à un point de collecte qui nous appartient, pour qu'une régression se voie au lieu de passer inaperçue.
• Le site ne peut pas être placé dans un cadre : X-Frame-Options est DENY et frame-ancestors est none.
• Referrer-Policy est strict-origin-when-cross-origin et la détection automatique des types MIME est désactivée.
• L'accès à la caméra, au micro et à la localisation est désactivé par politique.
• Les opérations qui coûtent de l'argent réel ou du temps de calcul réel, comme les exports, les PDF de certificat, le carnet d'enregistrement envoyé par e-mail, la remise des examens et tout ce qui appelle notre prestataire de paiement, portent toutes une limite de fréquence. Les compteurs vivent dans la base de données partagée plutôt que dans la mémoire de chaque serveur, indexés sur la personne, et sur l'entreprise en plus pour les plus lourds, de sorte qu'une limite publiée veut dire la même chose partout en même temps.

• Chaque page et chaque action serveur commence par vérifier le rôle de la personne connectée. Rien ne s'affiche d'abord pour être vérifié ensuite.
• Les rôles sont administrateur d'entreprise, responsable de secteur, responsable de site, chef de service, chef de service adjoint, employé, et notre propre administrateur de plateforme. Un responsable de secteur voit un secteur. Un responsable de site voit un site. Un chef de service voit un service.
• Sous l'administrateur d'entreprise, personne ne peut agir sur une personne de rôle égal ou supérieur, et personne ne peut élever qui que ce soit, y compris soi-même, au-delà de ce que son propre rôle peut attribuer.
• Chaque identifiant envoyé par le navigateur est vérifié contre l'entreprise et le périmètre de l'appelant avant toute écriture.
• La suppression définitive est réservée à notre rôle d'administrateur de plateforme et exige de retaper le nom de l'entreprise, ou le mot DELETE.

• Toute requête qui renvoie des données d'entreprise porte un filtre d'entreprise, appliqué par un utilitaire partagé plutôt que réécrit sur chaque page.
• Le périmètre échoue en mode fermé. Un responsable de site sans site attribué ne correspond à personne, jamais à toute l'entreprise.
• Row level security est active sur chaque table, sans politiques, ce qui ferme ces tables à l'API publique de Supabase. Un script de contrôle signale toute table restée ouverte et se termine en erreur.
• Les tentatives d'un client vers un autre sont couvertes par des tests : écrire dans le site d'une autre entreprise, lire l'équipe d'un autre site, agir au-dessus de son propre rôle, atteindre les relevés d'une autre entreprise.
• Ces tests s'exécutent sur une vraie base PostgreSQL et non sur des simulacres, et la suite doit passer avant toute mise en production.

• La connexion est gérée par Clerk, par e-mail et par Google. L'application ne voit ni ne conserve jamais de mot de passe.
• Les employés arrivent par un lien d'invitation personnel. Ce lien est un jeton aléatoire, il cesse de fonctionner dès que le compte existe, et les consultations sont limitées à dix par minute depuis une même adresse.
• Retirer un employé met fin à son accès dès sa requête suivante tout en conservant le dossier de formation dont l'entreprise a besoin lors d'un contrôle. C'est réversible.
• Un écran partagé en salle se connecte avec un seul code de site. Le code et le jeton de session associé ne sont conservés que sous forme de hachages SHA-256, le cookie est http-only et secure, les codes erronés s'arrêtent après cinq tentatives puis sont retardés jusqu'à quinze minutes, et la comparaison est à temps constant.
• Un écran de salle n'est pas une personne et n'atteint aucune page de l'application de gestion, car chacune de ces pages demande un rôle à un utilisateur connecté et un écran n'en a pas.
• L'authentification unique d'entreprise n'existe pas. Il n'y a ni connexion SAML ou OIDC, ni synchronisation d'annuaire (SCIM). Chacun se connecte avec un e-mail ou Google, et les comptes sont créés et supprimés dans HACCP Hyve.

• Les paiements passent par Stripe. Les données de carte n'atteignent jamais nos serveurs et ne sont jamais stockées dans notre base.
• Le paiement et le portail de facturation sont hébergés par Stripe.
• Les webhooks Stripe sont vérifiés contre un secret de signature avant toute application.
• Chaque événement de webhook est revendiqué par son identifiant, une livraison répétée ne change donc rien. Si un traitement échoue, la revendication est libérée et la requête renvoie une erreur, pour que Stripe livre à nouveau au lieu que la reprise soit lue comme un doublon.

• Supabase réalise des sauvegardes quotidiennes automatiques en formule Pro, confirmé le 8 août 2026.
• Nous réalisons aussi nos propres exports logiques complets, schéma et données, conservés hors du compte d'hébergement pour survivre à la perte du projet ou du compte lui-même.
• Les douze derniers exports sont conservés, les plus anciens sont supprimés.
• Une restauration a été testée le 16 juillet 2026 dans une instance PostgreSQL séparée. Le nombre de lignes et les numéros de certificat correspondaient à la production.
• La restauration à un instant précis n'est pas activée. C'est une décision du 17 juillet 2026, et c'est pourquoi le point de reprise ci-dessous se mesure en une journée et non en minutes.
• Nous nous engageons sur un point de reprise de 24 heures et une durée de rétablissement de 24 heures. La durée de la restauration testée n'a pas été relevée, nous nous engageons donc sur le chiffre dont nous sommes certains plutôt que sur un chiffre plus rapide.

• Nous nous engageons sur 99,5% de disponibilité sur un mois calendaire, mesurée sur l'accessibilité de l'application.
• La disponibilité est mesurée depuis l'extérieur de l'application par un service indépendant, et non par l'application qui rendrait compte d'elle-même. Les contrôles portent sur le site public, la connexion et un contrôle d'état qui exécute une vraie requête en base de données, de sorte qu'une page qui s'affiche encore alors que les données derrière elle ont disparu compte comme une panne.
• L'état actuel et l'historique des incidents sont publiés sur status.haccphyve.com. Cette page est hébergée indépendamment de l'application et reste donc accessible pendant une panne. La mesure externe continue a commencé le 25 août 2026 : l'historique mesuré part de cette date et pas au-delà.
• Les avoirs de service ne font pas partie des conditions standard. Un accord entreprise peut les ajouter.
• Vercel et Supabase publient leurs propres engagements de disponibilité. Le chiffre ci-dessus est le nôtre, il ne reprend pas le leur.

• Les changements sur les personnes, les rôles, les affectations de formation, les écrans de salle, les abonnements et les réglages d'entreprise sont écrits dans un journal d'audit indiquant l'entreprise, qui a agi, ce qui a été fait, sur quel enregistrement et quand.
• Les lectures sont enregistrées, pas seulement les modifications. Notre administrateur de plateforme qui ouvre le compte d'un client, quelqu'un qui ouvre un certificat qui n'est pas le sien, chaque export du registre de formation et chaque lecture de l'effectif via notre API laissent une ligne dans ce même journal.
• Quand notre administrateur de plateforme regarde l'application sous un rôle inférieur pour aider, le début et la fin de cette vue sont tous deux enregistrés. Ce qui est fait pendant reste attribué à la personne réelle, jamais au rôle consulté.
• Le journal d'audit est lisible par notre rôle d'administrateur de plateforme, et les entrées propres à une entreprise peuvent lui être remises sur demande.
• Le journal d'audit est en ajout seul dans la base de données elle-même, pas seulement dans notre code. PostgreSQL refuse toute modification d'une ligne et refuse d'en supprimer une à moins que la transaction qui le fait ne se déclare elle-même effacement licite. Chaque ligne qu'un effacement retire est écrite dans le journal propre au serveur de base de données, qui vit en dehors de cette base.
• Les journaux d'exécution sont conservés par Vercel pour la durée que prévoit sa formule.
• Les rapports de Content Security Policy arrivent sur un point de collecte dédié, limité en fréquence par adresse.
• Un point de terminaison de version indique le commit, l'environnement et la région qui servent, de sorte qu'une mise en production se confirme depuis l'extérieur de l'application.

Sept sociétés extérieures interviennent dans le fonctionnement du service. C'est la même liste que dans notre accord de traitement des données.

• Vercel, hébergement de l'application, région européenne
• Supabase, base de données PostgreSQL, région européenne
• Clerk, authentification et identité
• Stripe, traitement des paiements
• Resend, e-mails transactionnels
• Cloudflare, la vérification anti-robot sur l'écran de connexion, intégrée par Clerk
• Google (YouTube), uniquement lorsqu'une entreprise ajoute elle-même un lien YouTube à son support de formation ; YouTube dépose alors ses propres cookies

Nous informons les clients avant l'ajout ou le remplacement d'un sous-traitant, et un client peut s'y opposer.

• Les données de production des clients européens sont stockées dans l'Union européenne et servies depuis Paris.
• Lorsqu'un sous-traitant est établi hors de l'Union européenne, le transfert repose sur une décision d'adéquation ou sur des clauses contractuelles types.
• Nous traitons les données personnelles selon le RGPD, et pour les clients au Japon selon l'Act on the Protection of Personal Information.

• Un administrateur d'entreprise exporte le registre de formation complet en CSV quand il le souhaite, sans nous le demander.
• Les certificats et le carnet de relevés quotidiens se téléchargent en PDF.
• Une personne peut être effacée sur demande. Son compte chez notre prestataire d'authentification, son dossier de formation et d'examens, et les entrées d'audit qui la décrivent sont tous supprimés.
• Une entreprise entière peut être effacée sur demande. Cela supprime chaque utilisateur, site, service, résultat d'examen, certificat, notification et entrée d'audit, ainsi que les comptes chez notre prestataire d'authentification et la fiche client chez Stripe.
• Nous traitons une demande d'effacement vérifiée sous 30 jours, et normalement sous cinq jours ouvrés.
• Les enregistrements de certificats sont conservés cinq ans après émission pour qu'une entreprise puisse montrer son historique à un inspecteur, sauf si l'effacement est demandé plus tôt.

Nous n'avons ni certification ISO 27001 ni rapport SOC 2, et aucun tiers n'a audité ces contrôles. Ce qui figure sur cette page est intégré au produit et peut être vérifié dessus. Si votre évaluation exige un fournisseur certifié, dites-le tôt et nous vous dirons clairement si nous pouvons y répondre.

Écrivez à privacy@haccphyve.com en indiquant ce que vous avez fait et ce que vous avez vu. Nous confirmons la réception sous deux jours ouvrés.

• Dites-le nous d'abord et laissez-nous le temps de corriger avant d'en parler à d'autres.
• N'exécutez pas de scans automatisés sur le site en production, et ne lisez, ne modifiez ni ne conservez les données de personne d'autre.
• Nous n'engagerons aucune action contre quiconque respecte ces deux points de bonne foi.

• Politique de Confidentialité
• Conditions d'Utilisation

Les équipes informatiques menant une évaluation formelle peuvent demander notre questionnaire de sécurité complété à privacy@haccphyve.com.