Mesures techniques et organisationnelles (TOMs)

Mesures au titre de l'art. 32 GDPR garantissant la sécurité du traitement des données à caractère personnel sur la plateforme NISD2.eu.

Dernière mise à jour : juin 2026.

Vue d'ensemble

Ce document décrit les mesures techniques et organisationnelles effectivement mises en œuvre par Simon Orzel en tant qu'exploitant de la plateforme NISD2.eu. Il s'agit d'un inventaire honnête, et non d'une liste de souhaits : nous ne mentionnons que ce qui est déjà en place.

Les mesures sont alignées sur IT-Grundschutz (BSI) et seront étendues à mesure que la plateforme se développe.

Hébergement dans l'UE

Le traitement en production des données à caractère personnel a lieu exclusivement au sein de l'UE :

  • Serveurs applicatifs et base de données PostgreSQL : Hetzner Online GmbH, centre de données Falkenstein/Nuremberg, Allemagne
  • Stockage des documents de preuve téléversés : AWS S3, région UE
  • Aucun traitement de données de production en dehors de l'UE. Les sous-services américains (Resend pour les e-mails transactionnels, xAI pour le pré-remplissage IA optionnel) ne traitent que les données nécessaires à leur fonction.
Chiffrement (art. 32, par. 1, point a) GDPR)
  • Chiffrement en transit : TLS pour toutes les connexions à la plateforme (HTTPS)
  • Chiffrement au repos : chiffrement côté serveur AWS S3 (AES256, défini explicitement à chaque téléversement via PutObject) ; données PostgreSQL sur l'infrastructure Hetzner
  • Les identifiants et clés d'API sont gérés via des variables d'environnement serveur, et ne sont pas stockés dans le code source ni dans les bases de données
Confidentialité (art. 32, par. 1, point b) GDPR)

Mesures garantissant la confidentialité :

  • Contrôle d'accès physique : les centres de données des hébergeurs (Hetzner, AWS) détiennent des certifications ISO 27001
  • Mesures relatives au personnel : l'accès aux systèmes de production et aux données à caractère personnel est limité à un groupe restreint et nommément désigné, tenu à la confidentialité. L'accès suit le principe du moindre privilège et est révoqué à la fin d'un rôle.
  • Authentification : connexion par adresse e-mail et mot de passe ou via Google OAuth 2.0. Les mots de passe sont stockés uniquement sous forme d'empreinte bcrypt avec un facteur de coût de 12, jamais en clair. Lors d'une inscription par mot de passe, l'adresse e-mail est confirmée une fois par code à usage unique, et les tentatives de connexion échouées sont limitées à 10 en 15 minutes par instance applicative. La plateforme ne propose pas de second facteur sur le parcours par mot de passe. Les personnes qui se connectent avec Google utilisent la MFA de leur propre compte Google.
  • Autorisations basées sur les rôles : admin, reviewer, member ; appliquées dans la couche applicative via le middleware tRPC
  • Isolation multi-tenant : chaque requête portant sur des données filtre au niveau de la base de données sur l'identifiant d'entreprise de l'utilisateur authentifié ; aucun pool de données partagé entre clients
  • Les mots de passe ne sont jamais stockés en clair. Chaque connexion est comparée à une empreinte bcrypt, y compris lorsqu'aucun compte n'existe pour l'adresse fournie, afin que le temps de réponse ne révèle pas qui est inscrit.
Intégrité (art. 32, par. 1, point b) GDPR)
  • Contrôle des saisies : journal d'audit de toutes les mutations consignant l'identifiant utilisateur, l'action, le type d'entité, l'horodatage, l'adresse IP, l'agent utilisateur et les valeurs avant/après
  • Détection d'altération du journal d'audit : chaque ligne d'audit porte une somme de contrôle SHA-256 sur son contenu, de sorte que toute modification d'une ligne est détectable
  • Contrôle des transferts : transmission des données uniquement via TLS ; tous les points d'accès authentifiés exigent une session valide
  • Documents de preuve : l'emplacement de stockage et les métadonnées sont enregistrés au téléversement ; un condensat SHA-256 optionnel fourni par le client peut être stocké aux côtés du fichier
  • Mécanisme de validation : au moment de l'approbation, l'état de l'exigence est figé dans une table d'historique des validations dont les entrées forment une chaîne SHA-256 (la somme de contrôle de chaque entrée couvre la précédente) - toute altération de l'historique est détectable de bout en bout
Disponibilité (art. 32, par. 1, point b) GDPR)
  • Sauvegardes de la base de données selon les valeurs par défaut du service Hetzner Cloud ; les détails de la configuration de sauvegarde actuelle sont disponibles sur demande
  • Stockage des documents de preuve dans AWS S3 avec les garanties de durabilité des objets fournies par AWS
  • Limitation de débit sur les tentatives de connexion, les points d'accès publics (vérification d'applicabilité, portail fournisseurs) et les points d'accès authentifiés gourmands en ressources (exports PDF, génération de certificats)
  • Les fichiers téléversés sont limités à 50 Mo par fichier
  • Affichage de disponibilité : nisd2.eu/status vérifie à chaque appel l'accessibilité de la base de données et affiche le résultat publiquement, avec une mise en cache de 30 secondes. Nous n'exploitons pas de surveillance continue avec alerte automatique.
Procédure de vérification régulière (art. 32, par. 1, point d) GDPR)
  • Ces TOMs sont vérifiées sur déclenchement par un événement et au moins une fois par an
  • Mises à jour des dépendances et des bibliothèques pertinentes pour la sécurité : Dependabot est activé pour faire remonter les correctifs de sécurité et les mises à jour de version sous forme de pull requests sur une cadence hebdomadaire
  • Obligations de notification : les violations de données à caractère personnel seront notifiées à l'autorité de contrôle compétente dans les 72 heures conformément à l'art. 33 GDPR
  • Pratique de développement : les modifications de code passent par des pull requests ; les vérifications de types TypeScript en mode strict sont appliquées ; des tests automatisés ciblés couvrent la logique critique pour la sécurité (par exemple la classification d'applicabilité)
Sous-traitants ultérieurs

Tous les sous-traitants ultérieurs sont liés par des contrats au titre de l'art. 28 GDPR. La liste complète figure dans le document DPA.

Voir la liste complète des sous-traitants ultérieurs (DPA)

Contact pour la protection des données

Les questions relatives à ces TOMs ou à notre traitement des données doivent être adressées à :

contact@nisd2.eu