Fonctionnalité

Sécurité & conformité RGPD

Les données cliniques de vos patients sont des données de santé sensibles. NanoPsy les chiffre au niveau du champ, avant qu'elles ne touchent la base de données — et vous donne les outils pour respecter vos obligations RGPD.

Chiffrement des données

Notes de séance et tokens tiers chiffrés avec Fernet (AES-128-CBC + HMAC-SHA256) avant tout stockage.

Authentification forte

Mots de passe hachés bcrypt (12 rounds) avec pré-hachage SHA-256. JWT avec rotation des tokens à chaque renouvellement.

Contrôle d'accès strict

Chaque accès vérifie que le praticien est propriétaire des données. Impossible d'accéder aux dossiers d'un autre cabinet.

Conformité RGPD

Suppression douce sur patients, documents et comptes. Droit à l'oubli respecté par purge définitive sur demande.

Chiffrement des données sensibles

Notes de séance

Chiffrement au niveau du champ

Fernet AES-128-CBC

Le contenu de chaque note clinique est chiffré avant d'être transmis à la base de données. Ce qui est stocké en base est du texte chiffré illisible — même un accès direct à la base de données ne révèle aucun contenu clinique.

Algorithme utilisé

Fernet (cryptography library) AES-128-CBC HMAC-SHA256

Fernet garantit à la fois la confidentialité (AES-128-CBC) et l'intégrité (HMAC-SHA256). Un texte altéré en base est détecté et refusé au déchiffrement.

Clé de chiffrement

La clé est chargée depuis la variable d'environnement ENCRYPTION_KEY au démarrage du serveur. Elle n'est jamais écrite dans le code ni dans la base de données.

Tokens d'intégration

Google Agenda & OAuth

Fernet

Les tokens d'accès et de rafraîchissement de Google Agenda, ainsi que les tokens OAuth des comptes liés, sont chiffrés avec le même algorithme Fernet avant stockage. Ils ne sont déchiffrés qu'au moment où l'API en a besoin.

Champs chiffrés en base

google_calendar_tokens.access_token_enc
google_calendar_tokens.refresh_token_enc
oauth_providers.access_token_enc
oauth_providers.refresh_token_enc

Authentification & sessions

Mots de passe

Les mots de passe ne sont jamais stockés. Seul leur empreinte est conservée, en deux étapes :

1

Pré-hachage SHA-256

Le mot de passe brut est d'abord haché en SHA-256 (64 octets). Cela neutralise la limite de 72 octets de bcrypt et garantit une entropie uniforme.

2

bcrypt — 12 rounds

Le hash SHA-256 est ensuite haché avec bcrypt à 12 rounds. Ce paramètre rend les attaques par force brute extrêmement coûteuses en temps CPU.

SHA-256 bcrypt 12 rounds

Tokens JWT & sessions

Access token

Courte durée de vie

30 minutes

Refresh token

Renouvellement silencieux

30 jours

Algorithme de signature

HS256

À chaque renouvellement de token, l'ancien refresh token est immédiatement révoqué en base. Un token volé ne peut donc pas être réutilisé une fois qu'un renouvellement a eu lieu.

Chaque session enregistre l'adresse IP et le User-Agent du navigateur. À la déconnexion, la session est marquée révoquée instantanément.

Réinitialisation & vérification

Lien de réinitialisation

1

Un token aléatoire (secrets.token_urlsafe) est généré côté serveur.

2

Son hash SHA-256 est stocké en base. Le token brut n'est jamais sauvegardé.

3

Expire après 2 heures. Marqué utilisé après usage : impossible de l'utiliser deux fois.

La réponse API est identique que l'email existe ou non — ce qui empêche l'énumération de comptes.

Contrôle d'accès & uploads

Isolation des données par praticien

Vérification systématique du practitioner_id

Chaque requête API qui retourne des données patient inclut un filtre sur practitioner_id = utilisateur_connecté. Même si un token valide était compromis, il ne peut accéder qu'aux données du cabinet auquel il appartient.

Ce qui est isolé par praticien

Dossiers patients
Notes cliniques
Documents
Factures
Séances
Agenda Google

La connexion avec Google Agenda utilise une protection CSRF : le paramètre state de OAuth2 est signé avec HMAC-SHA256 et vérifié par comparaison en temps constant (hmac.compare_digest) au retour.

Téléversement de documents

Validation stricte des fichiers

10 Mo

Taille max

10

Types autorisés

200

Chars nom max

Types MIME autorisés

application/pdf image/jpeg image/png image/gif image/webp text/plain application/msword application/vnd.openxmlformats (docx) application/vnd.ms-excel application/vnd.openxmlformats (xlsx)

Les noms de fichiers sont sanitizés avant stockage : les caractères spéciaux sont retirés, le nom est tronqué à 200 caractères. L'accès en téléchargement vérifie que le practitioner_id correspond avant de retourner le fichier.

Conformité RGPD

Suppression douce

Droit à l'oubli

Les patients, documents et comptes ne sont pas effacés immédiatement. Un champ deleted_at est horodaté, rendant l'enregistrement invisible dans l'application.

Une purge définitive est disponible pour respecter les demandes d'effacement — suppression physique en base, avec suppression des fichiers associés sur le disque.

patients.deleted_at documents.deleted_at users.deleted_at

Suppression de compte

Révocation complète

Quand un compte est supprimé, toutes ses sessions actives sont révoquées simultanément. Aucun token existant ne peut plus être utilisé, même s'il n'a pas encore expiré.

Compte marqué is_active = false

Toutes les sessions : revoked_at horodaté

deleted_at positionné sur le compte

Validation des données entrantes

Pydantic + bibliothèques spécialisées

Emails validés avec EmailStr Pydantic

Numéros de téléphone normalisés en E.164 via phonenumbers

Mot de passe minimum 8 caractères, vérifié serveur

Toutes les requêtes SQL via SQLAlchemy ORM — aucun SQL brut non paramétré

Réservation publique : rate limiting 5 req/min par IP (protection spam)

Vos données cliniques méritent mieux qu'un tableur

Gratuit jusqu'à 10 patients actifs. Aucune carte bancaire requise.

Toutes les fonctionnalités incluses dès l'inscription.