À propos — souveraineté, sécurité et secret médical

Chaque praticien dispose d'un agenda (plages d'ouverture, créneaux bloqués), d'une vitrine publique (présentation + calendrier de réservation) et de statistiques d'activité agrégées et non nominatives.

Les patients prennent rendez-vous sur les créneaux disponibles ; le calendrier se synchronise en temps réel. La plateforme est distribuée en cellules — chaque cellule est une base de données autonome, chiffrée, ajoutée selon le volume réel d'utilisation.

La plateforme est éditée par une entreprise française indépendante. Les données de vos patients ne sont pas une source de revenu :

• Aucune revente de données à des tiers.
• Aucune exploitation commerciale : pas de publicité ciblée, pas de profilage.
• Propriété : vos données et celles de vos patients restent les vôtres.
• Réversibilité : export et départ sans rétention — si vous quittez la plateforme, vos données sont restituées ou supprimées à votre demande.
• Accès limité : les équipes techniques n'accèdent aux données de santé qu'en cas de nécessité opérationnelle stricte, jamais dans un autre but.

Le coût maîtrisé de la plateforme repose sur ce modèle : pas de monétisation des données, pas de frais cachés.

Le secret médical est partitionné par cellule : les clés de chiffrement d'une cellule ne sont jamais partagées avec une autre. Un incident limité à une cellule ne compromet pas les autres.

Le questionnaire de santé associé à un rendez-vous est rattaché à un numéro de visite généré côté serveur — jamais à l'identité nominative du patient. Aucune donnée de santé n'est exploitée à d'autres fins que la coordination du soin.

Toutes les données personnelles sont chiffrées au repos (AES-256-GCM). Les clés de chiffrement sont dérivées et gérées par un coffre interne (vault) : ni exposées à l'extérieur du service, ni enregistrées dans les journaux applicatifs.

La recherche s'effectue par empreinte non réversible : la plateforme retrouve un enregistrement sans jamais déchiffrer l'ensemble de la base. Le transport est chiffré en TLS 1.3. Les sessions sont signées. La connexion utilise mot de passe + code de vérification (OTP) ou un fournisseur d'identité (Google, Pro Santé Connect).

flowchart LR
  D["Donnée en clair"]:::plain
  subgraph WRITE["Écriture"]
    AES["Chiffrement\nAES-256-GCM\n(clé coffre)"]:::enc
    HM["Empreinte de recherche\n(non réversible)"]:::blind
  end
  DB[("Base chiffrée\ncellule N")]:::db

  D --> AES --> DB
  D --> HM --> DB

  subgraph READ["Recherche"]
    Q["Requête"]:::plain
    QH["Empreinte\nde la requête"]:::blind
    MATCH["Correspondance\nsur empreinte"]:::enc
    DEC["Déchiffrement\n(ligne trouvée)"]:::enc
    R["Résultat"]:::plain
  end
  Q --> QH --> MATCH
  DB --> MATCH --> DEC --> R

  style WRITE fill:#f8faff,stroke:#3b6fd4;
  style READ  fill:#f8faff,stroke:#27ae60;
  classDef plain fill:#fff,stroke:#64748b,color:#1e293b;
  classDef enc fill:#e8f0fe,stroke:#3b6fd4,color:#1a2e6b;
  classDef blind fill:#f3e8ff,stroke:#8b5cf6,color:#3b1080;
  classDef db fill:#eef2f7,stroke:#64748b,color:#1e293b;

L'infrastructure est hébergée en France, sans dépendance à un cloud extra-européen (pas d'AWS, Azure ni GCP). Chaque cellule est déployée sur des serveurs physiquement situés sur le territoire national.

L'architecture technique est conçue pour permettre une migration vers un hébergeur certifié HDS (Hébergeur de Données de Santé) sans modifier le métier applicatif. La certification HDS est un objectif cible — pas une certification actuelle.

flowchart TB
  subgraph FRONTS["Interfaces (un seul bundle)"]
    CLI["medcli — patient"]:::f
    PRO["medpro — praticien"]:::f
    ADM["medadm — admin"]:::f
  end
  NG["nginx (TLS 443)"]:::net
  CLI --> NG
  PRO --> NG
  ADM --> NG
  NG -->|"127.0.0.1:20003"| APP["Backend Go\nAPI + SPA"]:::app

  subgraph VAULT["Coffre de clés (réseau interne Docker)"]
    K1["vault keysvc1\ngRPC :50051"]:::vault
    K2["vault keysvc2 (réplique)"]:::vault
  end
  APP -->|"dérivation clés\nnon exposées"| K1
  K1 -.- K2

  subgraph CENTRAL["Index central"]
    IDXC[("Clients\nemail → cellule")]:::central
    IDXP[("Praticiens\nRPPS · ville · spécialité")]:::central
  end
  APP --> IDXC
  APP --> IDXP

  subgraph CELLS["Cellules (1 base PostgreSQL / cellule — chiffrée)"]
    C1[("cellule 1\nRDV chiffrés AES-256-GCM")]:::db
    CN[("cellule N…\nallouée au volume")]:::db
  end
  APP -->|"session → cellule"| C1
  APP --> CN

  classDef f fill:#e8f0fe,stroke:#3b6fd4,color:#1a2e6b;
  classDef net fill:#fff4e5,stroke:#d98324,color:#5a3a00;
  classDef app fill:#eafaf1,stroke:#27ae60,color:#0f4c25;
  classDef vault fill:#f3e8ff,stroke:#8b5cf6,color:#3b1080;
  classDef central fill:#fdecec,stroke:#c0392b,color:#5c1111;
  classDef db fill:#eef2f7,stroke:#64748b,color:#1e293b;

Pour qu'un espace praticien ne puisse être ouvert qu'au nom d'un professionnel réellement inscrit au RPPS, l'identité est vérifiée via Pro Santé Connect (carte CPS / e-CPS, Agence du Numérique en Santé), qui retourne le numéro RPPS vérifié à la source.

Un second contrôle interroge l'annuaire national pour confirmer que le RPPS est actif. Ce double contrôle (Pro Santé Connect + annuaire national) rend l'ouverture d'un compte au nom d'un tiers extrêmement difficile.

Les données suivent un cycle défini et limité dans le temps :

• Création : données minimales collectées à la prise de rendez-vous.
• Conservation : le temps utile au soin, selon les durées légales applicables.
• Anonymisation : suppression de l'identité nominative après le rendez-vous ; seule une ligne agrégée non nominative est conservée pour les statistiques d'activité.
• Suppression : les données nominatives sont supprimées à l'issue de la durée de conservation.

Le patient peut exercer son droit à l'effacement à tout moment depuis « Mon compte ». Les durées de conservation sont définies et documentées dans le registre des traitements.

flowchart LR
  A["Patient prend RDV\n(données nominatives)"]:::step
  B["Soin réalisé\n(conservation utile)"]:::step
  C["Anonymisation\n(identité supprimée,\nvisite en agrégat)"]:::anon
  D["Données nominatives\nsupprimées"]:::purge
  E["Agrégats statistiques\nnon nominatifs conservés"]:::stat
  F["Droit d'effacement\n(compte supprimé\nsur demande)"]:::right

  A --> B --> C --> D
  C --> E
  A -->|"À tout moment"| F

  classDef step fill:#e8f0fe,stroke:#3b6fd4,color:#1a2e6b;
  classDef anon fill:#fff4e5,stroke:#d98324,color:#5a3a00;
  classDef purge fill:#fdecec,stroke:#c0392b,color:#5c1111;
  classDef stat fill:#eafaf1,stroke:#27ae60,color:#0f4c25;
  classDef right fill:#f3e8ff,stroke:#8b5cf6,color:#3b1080;

Les rappels et confirmations de rendez-vous sont envoyés par notification push et e-mail, inclus sans surcoût dans la plateforme.

Le SMS n'est pas implémenté dans la version actuelle. C'est un canal payant à l'unité (coût par message facturé par l'opérateur téléphonique). Il pourra être proposé en option payante, activée par le praticien pour ses patients, s'il le souhaite.

Cette architecture maintient le coût maîtrisé de la plateforme : pas de frais cachés, pas de facturation de messages en dehors d'une option explicitement choisie et activée.

Les statistiques affichées (nombre de visites, répartition par sexe / tranche d'âge, type de visite, estimation de chiffre d'affaires) sont des agrégats non nominatifs, visibles de vous seul et non transmis à des tiers. Ces agrégats sont les seules données du passé conservées après anonymisation.

Ils ne servent pas au ciblage publicitaire et ne sont pas revendus.

La conformité RGPD est intégrée dès la conception (privacy by design). La démarche repose sur :

• Minimisation : collecte limitée aux données nécessaires.
• Base légale : identifiée pour chaque traitement.
• Droits des personnes : accès, rectification, effacement, portabilité — exercés directement depuis l'interface.
• Registre des traitements : tenu et mis à jour (art. 30 RGPD).
• Sous-traitants : encadrés contractuellement (art. 28 RGPD).
• Notification de violation : procédure de notification à la CNIL sous 72 h définie et testée.
• DPO : désigné et joignable (coordonnées dans les Mentions légales).