Sécurité & conformité

Des données de santé protégées comme elles le méritent

Chiffrement AES-256-GCM, hébergement HDS certifié en France, 2FA obligatoire, traçabilité complète. Kliniacare est conçu comme un coffre-fort, pas comme un simple outil de gestion.

Obligation légaleExigence réglementaire (RGPD, HDS, AI Act)
Kliniacare va plus loinMesure supplémentaire implémentée par Kliniacare
HDS certifié
Décret 2018-137
RGPD by design
Art. 25 & 32
AI Act conforme
Règlement EU 2024/1689
Made in France
Données en France

Hébergement HDS — exclusivement en France

Hébergeur certifié HDS (Décret 2018-137)

Obligation légale

Scalingo SAS, certifié HDS (certificat n° 38436, valide jusqu'en 2028) et ISO 27001 ; centres de données en France (Paris). DPA signé le 26 mars 2026.

Infrastructure OVHcloud en France

Obligation légale

Documents et sauvegardes stockés chez OVHcloud, en France. Certifié HDS, ISO 27001/27017/27018/27701, SOC 2 Type II.

Données de santé stockées en France

Obligation légale

Les dossiers et documents de santé sont stockés en France, chez des hébergeurs certifiés HDS. Les seuls transferts hors UE concernent le paiement et certaines fonctions d'IA sur des textes pseudonymisés, encadrés par des clauses contractuelles types.

Sauvegardes Borg chiffrées 3-2-1

Kliniacare va plus loin

Sauvegardes quotidiennes sur 3 sites, 2 médias différents, 1 site distant. Mode append-only contre les ransomwares. Rétention 90 jours.

Chiffrement des données

Chiffrement au repos — AES-256-GCM

Obligation légale

Chaque cabinet dispose d'une clé de chiffrement dérivée par HKDF-SHA256. Les données cliniques sensibles sont chiffrées au niveau champ avant stockage.

Chiffrement en transit — TLS 1.2 et 1.3

Obligation légale

Toutes les connexions utilisent TLS 1.3 avec forward secrecy. HSTS préchargé, redirection HTTPS systématique.

Gestion des clés via KMS OVH

Kliniacare va plus loin

Les clés de chiffrement sont protégées par un Key Management Service (KMS) hébergé en France. Séparation stricte entre clés et données chiffrées.

Clé dérivée par cabinet (HKDF-SHA256)

Kliniacare va plus loin

Chaque cabinet dispose de sa propre clé dérivée. Même en cas de compromission d'un cabinet, les autres restent protégés.

Authentification et contrôle d'accès

2FA TOTP obligatoire pour les praticiens

Obligation légale

Authentification à deux facteurs obligatoire pour tous les praticiens, secrétaires, direction et administrateurs (TOTP via Google Authenticator, Aegis ou équivalent).

Mots de passe conformes NIST SP 800-63B

Obligation légale

Minimum 14 caractères, vérification sur base HaveIBeenPwned, politique de complexité adaptée.

RBAC 6 rôles + 52 permissions

Kliniacare va plus loin

Contrôle d'accès granulaire basé sur les rôles. Chaque action est vérifiée côté serveur avec le principe du moindre privilège.

Isolation stricte par cabinet

Kliniacare va plus loin

Chaque requête est filtrée par cabinet au niveau applicatif : un cabinet ne peut pas accéder aux données d'un autre. Des politiques Row-Level Security PostgreSQL sont en cours de déploiement comme seconde barrière.

JWT RS256 + device fingerprinting

Kliniacare va plus loin

Sessions signées par paires de clés RSA. Empreinte d'appareil pour détecter le vol de session. Maximum 5 sessions simultanées par utilisateur.

Rate limiting multi-tier + protection brute force

Kliniacare va plus loin

Limitation de débit par IP, par utilisateur et par endpoint. Détection et blocage automatique des attaques par force brute.

Traçabilité et audit

Journalisation de tous les accès PHI

Obligation légale

Chaque accès aux données de santé est journalisé : qui, quoi, quand, depuis où. Conservation conforme au référentiel HDS.

Logs immuables HMAC-SHA256

Kliniacare va plus loin

Chaîne de hachage HMAC-SHA256 : chaque log est lié au précédent. Toute modification rétroactive est détectable. Conservation au moins 20 ans, comme les dossiers patients.

Détection DLP (Data Loss Prevention)

Kliniacare va plus loin

Surveillance en temps réel des flux de données pour détecter et bloquer les fuites de données sensibles.

Intelligence artificielle — AI Act

Classification des risques IA (4 niveaux)

Obligation légale

Chaque fonctionnalité IA est classifiée selon les 4 niveaux de risque du Règlement EU 2024/1689 : minimal, limité, haut, inacceptable. Mesures de contrôle adaptées automatiquement.

Évaluation d'impact FRIA

Obligation légale

Évaluations d'impact sur les droits fondamentaux (Fundamental Rights Impact Assessment) réalisées pour chaque fonctionnalité IA à haut risque.

Pseudonymisation avant envoi à l'IA

Obligation légale

Pour les fonctions cliniques les plus sensibles, seuls des fournisseurs établis en France sont utilisés (Mistral AI, Scaleway, OVHcloud). Lorsque d'autres fonctions font appel à OpenAI ou Anthropic, le texte est pseudonymisé avant l'envoi.

Métadonnées de transparence

Kliniacare va plus loin

Chaque réponse IA est accompagnée de métadonnées : modèle utilisé, niveau de risque, score de confiance, tokens consommés. Journalisation complète.

Politique de supervision humaine

Kliniacare va plus loin

L'IA assiste le praticien, ne décide jamais à sa place. Le consentement du patient est requis pour chaque usage IA clinique. 8 finalités de consentement distinctes.

52
permissions RBAC
20 ans min.
rétention logs audit
5 max
sessions simultanées

Une question sur la sécurité ou la conformité ?

Notre DPO répond directement aux questions techniques et conformité. Pour les audits approfondis, nous mettons à disposition la documentation complète sur demande (registre de traitement, DPIA, FRIA, politique de sécurité).