Politique de sécurité

Synthèse publique des mesures techniques et organisationnelles mises en œuvre pour protéger la plateforme et les données qu'elle traite. Document de transparence : ne se substitue pas à la documentation technique interne.

Dernière mise à jour : 2026-06-14

Informations légales en cours de finalisation

La plateforme est actuellement en phase de démonstration avec données fictives uniquement. Les coordonnées éditeur complètes (raison sociale, SIREN, adresse postale) seront publiées dès la constitution de l'entité juridique.

1. Statut de la plateforme

La plateforme est en Phase 1 · MVP démonstration, données fictives uniquement. Elle ne traite aucune donnée de santé réelle et n'est pas hébergée chez un prestataire certifié HDS. La bascule HDS est planifiée pour la Phase 2 (voir charte et roadmap interne).

2. Authentification et gestion des sessions

  • Mots de passe hachés avec Argon2id (paramètres conformes aux recommandations OWASP 2024).
  • Sessions matérialisées par deux cookies httpOnly + SameSite=Lax + Secure en production : wp_access (15 min) et wp_refresh (7 jours).
  • Pas de stockage de jeton en localStorage ou sessionStorage (protection contre les attaques XSS de vol de jeton).
  • Authentification fédérée Pro Santé Connect prévue en Phase 2.
  • MFA obligatoire en Phase 2 pour tout utilisateur accédant à des données patient.

3. Chiffrement des données

  • NIR (Numéro d'Inscription au Répertoire) : haché + stocké séparément, le NIR en clair est chiffré AES-256-GCM dans un vault dédié.
  • Communications client/serveur en HTTPS (TLS 1.2+), HSTS activé en production.
  • Chiffrement at-rest fourni par l'hébergeur (chiffrement des disques par défaut chez Clever Cloud, en France).
  • Chiffrement applicatif at-rest de l'identité civile du patient (nom, prénom, date de naissance) dans un coffre dédié, au même titre que le NIR.
  • Chiffrement applicatif des photos cliniques avant stockage objet, déchiffrées à la volée via un proxy authentifié.

4. Traitement des photos cliniques

  • Suppression automatique des métadonnées EXIF (notamment GPS) avant stockage, via sharp.
  • Stockage hors base de données, sur un bucket S3-compatible privé.
  • Accès via URLs pré-signées à durée de vie courte (5 minutes), non indexables.
  • Aucune photo n'est exposée publiquement.

5. Audit et traçabilité

  • Journal d'audit applicatif chaîné par hash (chaque entrée intègre le hash de l'entrée précédente, conformément à l'esprit de la PGSSI-S) afin de détecter toute altération a posteriori.
  • Traçabilité de tout accès aux données patient (utilisateur, action, horodatage, ressource).
  • Conservation des logs : 1 an en Phase 1, 3 ans en Phase 2 (PGSSI-S minimum).
  • Logs applicatifs scrubbés des données patient identifiantes (audit de Phase 2 prévu).

6. Cloisonnement par rôle

  • Modèle d'autorisation par rôle (requérant, requis, administrateur) et par propriété de la ressource (un requérant ne voit pas les cas d'un confrère).
  • Garde AdminGuard distincte de l'authentification générale pour l'accès aux pages d'administration.
  • Tests automatisés (Jest) couvrant les règles d'isolation par rôle (test grandeur nature : 60/60 PASS).

7. Hébergement et sous-traitants

L'infrastructure repose sur les prestataires suivants :

  • Clever Cloud SAS : Hébergement applicatif (Next.js, NestJS, PostgreSQL), centres de données situés en France.
  • Clever Cloud SAS (Cellar) : Stockage objet S3-compatible (photos cliniques de démonstration), données en France.

L'ensemble de l'infrastructure est localisé en France, au sein de l'Union européenne. En Phase 2 (ouverture clinique), l'hébergement sera assuré par un prestataire certifié « Hébergeur de Données de Santé », également situé en France.

8. Notifications par email

La plateforme envoie des emails de notification (nouveau cas à traiter, avis rendu) sans aucune donnée patient identifiante en pièce jointe ou dans le corps. Le mail contient uniquement un lien vers la plateforme. MSSanté (Mailiz) sera intégré en Phase 2 comme canal de notification, conformément à la PGSSI-S.

9. Développement et qualité logicielle

  • Code source en TypeScript strict, typecheck obligatoire avant merge.
  • Plus de 260 tests unitaires automatisés (Jest) sur les services critiques : contrôle d'accès, audit, NIR, facturation, expertise, MFA, garde admin.
  • Test E2E exhaustif scripts/e2e-smoke.sh (60/60 PASS).
  • Intégration continue (GitHub Actions) : typecheck + lint + test + build à chaque push.
  • Revues de code via pull requests, pas de push direct sur la branche principale.

10. Politique de divulgation responsable

Une vulnérabilité ? Signalez-la en privé à __TODO__ contact@eizor.fr. L'éditeur s'engage à accuser réception sous 72 heures, à confirmer la qualification sous 7 jours, et à publier un correctif dans des délais proportionnés à la sévérité. Aucune poursuite ne sera engagée contre un chercheur agissant de bonne foi et dans le cadre d'une divulgation responsable.

11. Évolutions prévues (Phase 2 HDS)

  • Hébergement chez un prestataire certifié HDS basé en France.
  • Désignation d'un DPO externe et rédaction d'une AIPD (Analyse d'Impact sur la Protection des Données).
  • Pen-test externe avant ouverture clinique.
  • Sauvegardes 3-2-1 chiffrées et restauration testée.
  • MFA obligatoire généralisée.
  • Pro Santé Connect opérationnel.
  • Intégration MSSanté / Mailiz réelle.
  • Signature électronique qualifiée eIDAS pour les ordonnances.