Ce site est un portfolio. Construit seul avec Claude Code pour explorer et démontrer la maîtrise de l'AI-augmented development dans la santé suisse. Objectif : trouver un poste Builder / Product / Tech dans la santé ou l'IA.

Mon LinkedIn
OGPS
← Retour au blog
Technique 7 avril 2026 · 6 min de lecture · par Raphmau

Architecture Multi-Tenant : La Killer Feature d'OGPS

L'architecture multi-tenant d'OGPS n'est pas juste une prouesse technique, c'est une réponse concrète à un problème réel : la mobilité professionnelle dans le secteur de la santé suisse.

Architecture Multi-tenant Technique

Ce post fait partie de ma démarche build-in-public. Réflexion en cours — les choix décrits ici peuvent évoluer.

Changer de cabinet ou intégrer une nouvelle structure, ça existe — mais c’est rarement simple. Les données ne migrent pas toutes. La configuration du logiciel source et celle du logiciel cible ne correspondent jamais exactement. Il faut un export, un import, une reprise manuelle, parfois plusieurs jours de travail selon la taille du cabinet et la complexité de l’organisation. Et au bout du compte, une partie de l’historique finit souvent dans un tiroir.

C’est un problème que j’ai voulu traiter dès le départ dans OGPS — pas comme une fonctionnalité à ajouter plus tard, mais comme le fondement même de l’architecture.

Le Problème Réel

En Suisse, la mobilité professionnelle dans le secteur de la santé est très élevée :

  • Une infirmière indépendante change de structure en moyenne tous les 2–3 ans
  • Un physiothérapeute peut travailler dans 2–3 cabinets simultanément
  • Un médecin remplaçant peut exercer dans 5–10 cabinets différents par an
  • Les collaborations entre cabinets sont très fréquentes (partage de patients, remplacements)

Avec les systèmes actuels, chaque changement de structure = perte de données, re-saisie manuelle, formation à un nouveau logiciel est chronophage, source d’erreurs, et frustrant.

La Solution OGPS : Multi-Tenant by Design

L’architecture multi-tenant d’OGPS signifie qu’un professionnel peut :

  1. Travailler dans plusieurs cabinets simultanément sans dupliquer ses données
  2. Migrer d’un cabinet à un autre en 1 clic sans perdre son historique
  3. Partager des patients entre cabinets (avec consentement patient)
  4. Gérer des remplacements sans friction technique

Exemple Concret : Marie, Infirmière Indépendante

An 1 : Marie exerce en solo, 80 patients dans OGPS

An 2 : Elle rejoint un cabinet de groupe → Migration en 1 clic, ses 80 patients + accès aux 200 patients du cabinet

An 3 : Elle collabore avec un cabinet médical → Partage de 30 patients communs, pas de doublon

An 4 : Elle retourne en solo → Récupère ses données en 1 clic, liberté professionnelle totale

Résultat : 4 changements de structure en 4 ans, zéro perte de données, zéro re-saisie manuelle.

Comment Ça Marche Techniquement ?

1. Séparation des Données

OGPS sépare strictement :

  • Données Cabinet (appartiennent au cabinet, cryptées)
  • Données Patient (appartiennent au patient, cryptées)
  • Données Professionnel (appartiennent au professionnel, cryptées)

Un patient = un seul dossier unique, accessible par tous les professionnels autorisés.

J’ai dû trancher une question architecturale importante : un cabinet par base de données (isolation totale, coût élevé) ou tous les cabinets dans une seule base avec isolation logique (complexité technique, performance supérieure) ? J’ai choisi la seconde option, avec un filtre automatique par cabinet sur chaque requête. Résultat : 50 cabinets dans une seule base de données PostgreSQL, chacun parfaitement isolé — ni un développeur distrait, ni un bug, ne peut faire fuir les données d’un cabinet vers un autre. L’isolation est structurelle, pas documentée.

2. Gestion Fine des Droits

Chaque utilisateur a des rôles multiples :

  • Marie peut être propriétaire de son cabinet solo (tenant 1)
  • Collaboratrice dans un cabinet de groupe (tenant 2)
  • Patiente dans le système (accès à son propre dossier)

Les droits d’accès sont gérés par Microsoft Entra ID (anciennement Azure AD) pour la sécurité et la conformité.

3. Migration Sans Friction

Quand Marie change de cabinet :

  1. Choix : Quelles données migrer ? (patients, agenda, documents)
  2. Validation : Consentement des patients pour le partage
  3. Migration : Transfert automatique des données autorisées
  4. Continuité : Historique complet préservé

Temps total : 5–10 minutes. Avec un système classique : plusieurs jours.

Pourquoi C’est Un Pari Technique Fort ?

L’architecture multi-tenant est complexe à développer :

  • 6–12 mois de développement pour une implémentation solide
  • Expertise technique en sécurité, cryptage, gestion des droits
  • Tests rigoureux pour éviter les fuites de données entre tenants
  • Conformité LPD by design, pas ajoutée après coup

Les systèmes qui n’ont pas fait ce choix dès le départ ne peuvent pas l’ajouter facilement. C’est un refactoring complet de leur architecture.

L’Effet de Réseau

Plus il y a de professionnels et de cabinets sur OGPS, plus la valeur augmente :

  • Partage de patients simplifié entre cabinets du réseau
  • Continuité des soins garantie même en cas de changement de professionnel
  • Élimination des doublons (3,2× → 1×)
  • Interopérabilité totale au sein de l’écosystème OGPS

C’est une architecture conçue pour la liberté, pas le verrouillage — la flexibilité profite à tous.

La Suite

Le prochain article détaille la sécurité by design d’OGPS : cryptage de bout en bout, conformité LPD, architecture zero-trust — et les 4 décisions concrètes qui rendent la sécurité structurelle plutôt qu’optionnelle.

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.