Ce post fait partie de ma démarche build-in-public. Réflexion en cours — les choix décrits ici peuvent évoluer.
Après 20 ans à la Caisse des Médecins — avec une petite équipe, on a construit Medionline de zéro jusqu’à +20000 utilisateurs — j’ai vu quelque chose que les chiffres confirment : le patient est le grand oublié du système de santé suisse.
Le Problème : Un Système Fragmenté
Aujourd’hui en Suisse :
- Un patient a en moyenne 3,2 dossiers médicaux différents entre ses différents professionnels de santé
- Les médecins passent 30–40% de leur temps sur des tâches administratives
- 12% des hospitalisations sont liées à des effets indésirables médicamenteux (souvent évitables)
- Le DEP officiel a moins de 1% d’adoption après 7 ans et des millions investis
- 400 millions CHF/an sont perdus en doublons et inefficiences
Ce système ne sert personne correctement. Pas les patients, pas les professionnels.
Pourquoi j’ai construit OGPS
J’ai passé 20 ans à construire des outils pour les professionnels de santé. Des outils solides, utiles, adoptés. Mais au fil du temps, une conviction s’est imposée : personne ne construit pour le patient.
Il paie les primes les plus élevées d’Europe. Il ne comprend pas ses factures. Il ne contrôle pas ses données. Tout le monde — éditeurs de logiciels, assureurs, cabinets — construit pour les professionnels ou pour les caisses. Le patient, lui, subit, même s’il a parfois des bons cadeaux s’il fait du sport.
Je suis convaincu qu’un patient mieux informé et engagé facilite le travail des professionnels, et que des professionnels libérés de l’administratif offrent de meilleurs soins. C’est un cercle vertueux, pas un jeu à somme nulle. OGPS est mon exploration de ce cercle vertueux.
Ma vision
Ce que j’explore avec OGPS : démontrer qu’avec une expertise métier, une vision produit claire et l’AI comme levier, on peut construire une architecture aussi rigoureuse que ce qui prenait une équipe entière — et l’appliquer à un problème réel et complexe comme la santé numérique suisse.
À plus long terme, si ce projet intéresse des professionnels, des cabinets, ou des patients : je serai là. Mais aujourd’hui, c’est avant tout une démonstration par l’exemple.
Ce que je construis
Deux axes guident chaque décision technique :
1. Architecture & Innovation Technique
- Multi-tenant : Un professionnel peut travailler dans plusieurs cabinets sans friction, sans perdre son historique
- Sécurité by design : Les données médicales sont protégées dès la conception, pas en patch après coup
- AI appliquée : Explication des factures en langage clair, détection d’anomalies — des cas d’usage concrets, pas de la théorie (enfin, théorique pour le moment mais qui ont du sens terrain).
2. Remettre le patient au centre
- Pour les patients : Contrôle de leurs données, accès à leur dossier complet, compréhension de leurs factures
- Pour les professionnels : Réduction de la charge administrative, mobilité entre cabinets sans friction
- Pour tous : Moins de doublons, continuité des soins, moins d’erreurs
Mes valeurs
Trois valeurs guident mes décisions — produit, contenu, architecture :
Pragmatisme : On construit ce qui marche, pas ce qui brille. 20 ans de mises en prod et de bugs corrigés en urgence enseignent le pragmatisme mieux que n’importe quel framework.
Honnêteté : Données factuelles, pas de promesses irréalistes. Les chiffres sont vrais, le parcours est vrai, l’humilité est vraie.
Bienveillance : Construire pour aider. Le patient d’abord. On peut être direct et bienveillant en même temps.
Pourquoi Maintenant ?
Le moment est propice :
- Échec documenté du DEP : Moins de 1% d’adoption après 7 ans — il y a clairement mieux à faire
- Maturité technologique : Cryptage, IA, cloud permettent enfin de construire ce qui n’était pas faisable il y a 10 ans
- Pénurie de professionnels : Le temps médical est précieux — chaque heure administrative économisée compte
- Claude Code : Construire seul en ~1h par feature ce qui prenait une équipe — c’est la vraie nouveauté de 2026
La Suite
Dans les prochains articles, je détaillerai ce que je construis, comment, et pourquoi certains choix techniques m’ont surpris :
- L’architecture multi-tenant (le défi technique central d’OGPS)
- La sécurité by design (cryptage, conformité LPD, ce que les autres font mal)
- La stack complète et le workflow Claude Code (~1h par feature, comment c’est possible)
Ce blog est une réflexion en cours. Les choix décrits ici évoluent au fil de la construction. C’est le principe du build-in-public : partager avant d’avoir toutes les réponses.
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.