Ce post fait partie de ma démarche build-in-public. Réflexion en cours — les choix décrits ici peuvent évoluer.
“Vos données sont sécurisées.” Combien de fois avez-vous entendu cette phrase ? Et combien de fois avez-vous vu des fuites de données dans les actualités quelques mois plus tard ?
Après 20 ans à construire un système qui traite des milliards de CHF de facturation médicale — j’ai une conviction forgée sur le terrain : la sécurité ajoutée après coup est complexe, voir une illusion. Dans OGPS, c’est le fondement même de l’architecture, pas une couche qu’on pose à la fin.
Le Problème : Sécurité Ajoutée vs. Sécurité by Design
La plupart des systèmes de santé sont construits ainsi :
- Phase 1 : On développe les fonctionnalités (gestion patients, facturation, etc.)
- Phase 2 : On ajoute un peu de sécurité (mot de passe, HTTPS)
- Phase 3 : On se rend compte que ce n’est pas suffisant
- Phase 4 : On essaie de “patcher” la sécurité après coup
Résultat : Architecture fragile, vulnérabilités multiples, conformité LPD approximative.
L’Approche OGPS : Security by Design
OGPS est construit différemment :
- Phase 1 : On définit les exigences de sécurité et de conformité
- Phase 2 : On conçoit l’architecture autour de ces exigences
- Phase 3 : On développe les fonctionnalités dans ce cadre sécurisé
- Phase 4 : On audite, on teste, on améliore en continu
Résultat : Sécurité native, conformité LPD by design, confiance des utilisateurs.
Les 5 Piliers de la Sécurité OGPS
1. Cryptage de Bout en Bout
Principe : Vos données médicales sont cryptées avant même de quitter votre appareil.
- Cryptage client-side : AES-256, clés générées localement
- Stockage crypté : Même moi je ne peux pas lire vos données sans votre clé
- Transmission sécurisée : TLS 1.3, certificats validés
Concrètement : Si un pirate accède à nos serveurs, il ne voit que du charabia crypté. Sans les clés (que seuls vous et les professionnels autorisés possédez), les données sont inutilisables.
Un détail que j’aime particulièrement : chaque donnée chiffrée porte la version de la clé qui a servi à la chiffrer. Quand je change de clé (rotation obligatoire pour la sécurité), je n’ai pas besoin de tout re-chiffrer en masse — opération risquée, coûteuse, avec une fenêtre de vulnérabilité. Les données existantes restent lisibles avec l’ancienne clé, les nouvelles utilisent la nouvelle. Zéro downtime, zéro migration périlleuse.
2. Séparation des Données by Design
OGPS sépare strictement :
- Données médicales (diagnostics, traitements, analyses)
- Données patient (identité, consentements, autorisations)
- Données cabinet (facturation, gestion, statistiques)
Chaque acteur n’accède qu’aux données dont il a besoin. Les données médicales pourraient être anonymisées pour la recherche sans risque de ré-identification.
Cette séparation n’est pas qu’une règle sur le papier — elle est gravée dans le code. Chaque requête vers la base de données porte automatiquement un filtre d’isolation par cabinet. Ce filtre n’est pas optionnel. Un professionnel qui travaille dans plusieurs cabinets ne peut pas, même par erreur, voir les données d’un autre. L’isolation n’est pas une bonne pratique à respecter : c’est une contrainte structurelle que le système impose.
3. Consentement Patient au Cœur du Système
Le patient contrôle qui accède à quoi, quand, et pourquoi :
- Granularité fine : Partager tout le dossier ou seulement certaines parties
- Révocation instantanée : Retirer un accès à tout moment
- Historique complet : Voir qui a consulté quoi et quand
- Consentement explicite : Pas d’accès par défaut, tout est opt-in
Concrètement : Un patient peut autoriser son médecin traitant à voir tout son dossier, mais limiter l’accès de son physiothérapeute aux seules données musculo-squelettiques.
J’ai dû trancher une question que peu de systèmes posent clairement : votre médecin a une fiche locale sur vous dans son cabinet (agenda, notes, historique des consultations). Votre dossier OGPS, lui, vous appartient. Ces deux choses ne sont pas liées automatiquement. Un cabinet ne peut pas “importer” votre historique OGPS sans votre consentement explicite, enregistré, traçable. Votre passeport médical reste dans votre poche.
4. Conformité LPD Native
OGPS respecte le LPD par conception, pas par ajout :
- Droit à l’oubli : Suppression définitive des données en 1 clic
- Portabilité : Export complet des données (PDF, XML, JSON)
- Rectification : Correction des données à tout moment
5. Architecture Zero-Trust
Principe : Ne faire confiance à personne, vérifier tout.
- Authentification forte : MFA obligatoire pour les professionnels
- Gestion des droits : Microsoft Entra ID, rôles fins, révision régulière
- Logs d’audit : Traçabilité complète de tous les accès
- Détection d’anomalies : IA pour identifier les comportements suspects
Sur l’audit, j’ai pris une décision que je considère comme l’une des plus importantes du projet : la traçabilité est automatique et structurelle. Chaque modification en base de données — création d’un dossier, mise à jour d’un diagnostic, suppression d’un document — est automatiquement capturée avec qui a agi, depuis quel cabinet, et quand. Ce n’est pas un log que le développeur pense (ou oublie) d’écrire. C’est un mécanisme au niveau de l’infrastructure. Et les registres d’audit sont immuables : on peut les consulter, jamais les modifier.
Comparaison : OGPS vs. DEP Officiel
Le Contrôle fédéral des finances a identifié 4 défaillances majeures du DEP :
| Critère | DEP Officiel | OGPS |
|---|---|---|
| Cryptage | Partiel, ajouté après coup | Bout en bout, by design |
| Consentement | Complexe, peu granulaire | Simple, granularité fine |
| Conformité LPD | Problématique selon CDF | Native, by design |
| Adoption | <1% après 7 ans | Architecture pensée pour la confiance |
La Suite
Dans le prochain article, j’analyserai en détail l’échec du DEP officiel : les 4 défaillances identifiées par le CDF, et comment j’imagine les éviter dans OGPS.
Ce blog est une réflexion en cours. Les choix techniques décrits ici sont ceux que j’ai faits aujourd’hui — ils peuvent évoluer au fil de la construction.
OGPS est un projet personnel — vision, architecture et exécution — une réflexion active sur ce que 20 ans dans la santé suisse, augmentés par l’AI, permettent de construire.