Sécurité & LGPD

Les données sensibles exigent des contrôles sérieux — c'est ainsi que nous traitons les vôtres

Chiffrement, contrôle d'accès basé sur la propriété et principes LGPD intégrés à l'architecture, non ajoutés après coup.

Données de santé sensibles : la voix, l'expression faciale et le contenu des séances thérapeutiques sont traités comme des données sensibles au sens de la LGPD brésilienne (loi 13.709/2018). Cette page décrit les contrôles techniques et organisationnels appliqués.

Protection des données

Comment les données de séance sont protégées

Chiffrement

Les données en transit sont protégées par TLS ; les données au repos sont stockées de façon chiffrée dans la base analytique.

Contrôle d'accès

Chaque rapport de séance est lié à la propriété du professionnel responsable — accès restreint par compte, non partagé librement par séance.

Anonymisation analytique

Les métriques agrégées utilisées pour la recherche interne reposent sur des hachages de séance et de patient, sans données directement identifiables dans la couche analytique.

Le fonctionnement, sans simplifier à l'excès

Le parcours réel d'une séance

Nous préférons décrire l'exploitation complète plutôt que la résumer d'une façon qui la ferait paraître plus simple qu'elle ne l'est.

Transmission et traitement

Les séances à distance utilisent WebRTC ; lorsque la connexion directe entre les appareils n'est pas possible, un serveur TURN agit comme relais. Une part importante des métriques est calculée dans le navigateur du professionnel ; des segments audio peuvent être envoyés au backend de FROID et à un prestataire de transcription spécialisé pour le traitement de la voix, de l'image et du texte.

Hébergement et sauvegardes

Les transcriptions, rapports et enregistrements autorisés sont stockés sur l'infrastructure de FROID, qui peut inclure un hébergement en Estonie et des prestataires de paiement, d'IA, d'e-mail et d'agenda — ce qui peut impliquer un transfert international de données, protégé par les mécanismes contractuels et techniques applicables. Les sauvegardes sont chiffrées et vérifiées périodiquement.

Isolation multitenant

Les données de chaque organisation (clinique ou professionnel indépendant) sont segmentées par sécurité au niveau des lignes (RLS) dans la base de données — par construction, une organisation ne peut pas accéder aux enregistrements d'une autre.

Audit des accès

L'accès, la modification, l'exportation et le refus d'accès aux rapports et données des patients sont enregistrés dans une piste d'audit, liée au compte ayant effectué l'action.

Conformité

LGPD et bonnes pratiques du secteur

Nous traitons les principes de la LGPD — finalité, nécessité, transparence et sécurité — comme des exigences architecturales, non comme une liste de contrôle appliquée après coup. Cela suit le même raisonnement que les standards internationaux de SaaS de santé (HIPAA, RGPD) : la conformité doit être intégrée au chiffrement, aux pistes d'audit et au contrôle d'accès fondé sur les rôles, pas seulement dans un contrat.

Pour les cliniques et professionnels qui souscrivent à FROID, nous mettons à disposition les conditions de traitement des données dans le cadre du processus d'inscription professionnelle.

Engagements actuels

  • Consentement explicite du patient avant chaque séance enregistrée
  • Droit à l'effacement des données sur demande
  • Notification en cas d'incident de sécurité

Modèle de responsabilité partagée

Comme pour tout SaaS de santé, la sécurité se répartit ainsi : FROID est responsable de l'infrastructure de la plateforme (chiffrement, sauvegardes, contrôle d'accès à l'application) ; la clinique/le professionnel souscripteur est responsable de la gestion de l'accès de son équipe et du consentement obtenu du patient.

Pile technique pertinente

Backend FastAPI avec persistance DuckDB pour l'analytique agrégée ; contrôle de propriété des rapports via _can_access_report() et _report_owner_email() ; hachage de séance anonyme via _anonymous_session_hash() avant toute agrégation statistique.

Durcissement de la plateforme et de l'infrastructure

  • Chiffrement : TLS en périphérie ; au repos, chiffrement authentifié Fernet (AES-128-CBC + HMAC-SHA256) avec rotation des clés via MultiFernet ; mots de passe avec PBKDF2-HMAC-SHA256 (120 000 itérations + sel).
  • En-têtes de sécurité : HSTS avec preload, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options : DENY, Referrer-Policy et Permissions-Policy (n'autorise que caméra/microphone).
  • Surface réseau réduite : les services internes ne sont pas publiés sur l'interface publique ; tout accès passe par Caddy en TLS ; pare-feu n'autorisant que 80/443 et SSH restreint.
  • Conteneurs sans privilèges : processus non-root, no-new-privileges, capabilities Linux supprimées (cap_drop : ALL) et limite de processus.
  • Défense applicative : validation du SQL généré par l'IA (liste blanche SELECT/WITH, connexion read_only, tables restreintes) ; limitation de débit sur l'authentification et l'ingestion ; limites de corps et timeouts en périphérie.
  • Intégrité en temps réel : le traitement du signal (F0/MFCC/enveloppe) s'exécute dans un thread pool pour ne jamais bloquer la boucle d'analyse lors de séances simultanées.
  • Exploitation : dépendances figées pour des builds reproductibles ; healthchecks par service ; sauvegardes chiffrées hors site avec test de restauration.